Drop the calendar's legacy authentication path

Step 5, the last one, of docs/calendar-auth-migration.md. Step 4 is deployed
and verified, which is what this was waiting on: it removes the fallbacks that
step 4 still leaned on.

Gone: src/models/calendar/users/ entirely - registration, login, activation,
both password-reset routes, and the session checking that the feedback and
tickets admin areas used to authenticate against - along with its mount. That
was the API's last unauthenticated account-creation and mail-sending endpoint.
A survey confirmed nothing outside that directory imported it and nothing else
touched its tables.

Also gone: the two joins against the calendar users table in events.service.ts
and the created_by_id / version_created_by_id columns they read, from the SQL,
the row mapper, the Event interface and the swagger schema; and X-Session-Id /
X-Session-Key from the CORS allowedHeaders, which nothing has read since the
first cutover and nothing has sent since the second.

An event's author still renders, because migration 002 snapshotted the names
before this could erase them. That was brought forward from this step on
purpose, and it is the reason 004 can rename the accounts aside at all.

The accounts are renamed rather than dropped - they still hold e-mail addresses
and password hashes, and a rename makes them unreachable without destroying
anything. InnoDB rewires the sessions foreign key to the new name; verified on
MariaDB 11, along with the whole 001-004 chain from the pre-cutover production
schema, which lands byte-identical to a fresh dev database.

Migration 004 must be applied AFTER deploying, not before - the reverse of step
4, whose migration only added things. Its own header and the runbook both say
so, since getting it wrong by analogy is the obvious mistake.

DEFERRED_SECURITY.md items 3 and 4 close with it: the activation and reset
tokens that never expired are gone along with the code that issued them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -33,15 +33,15 @@ Express.js REST API in TypeScript with a service-oriented layering. Domains: `Ca
 
 | Layer | Location |
 |---|---|
-| Router | `src/models/calendar/Calendar.router.ts`, `…/events/events.router.ts`, `…/users/users.router.ts` |
-| Services | `…/events/events.service.ts`, `…/users/users.service.ts`, `…/events/credentials.service.ts`, `…/events/icalgenerator.service.ts` |
+| Router | `src/models/calendar/Calendar.router.ts`, `…/events/events.router.ts` |
+| Services | `…/events/events.service.ts`, `…/events/credentials.service.ts`, `…/events/icalgenerator.service.ts` |
 | DB pool | `src/models/calendar/Calendar.db.ts` (MariaDB, pool size 5) |
 | Shared | `src/common/` (base route class, nodemailer wrapper), `src/middleware/logger.ts` (Winston) |
 
-**Auth model:** Two of them, on purpose.
+**Auth model:** One, since the calendar migration completed.
 
-*Admin module (`src/models/admin/`)* — the current one, used by feedback, tickets and the
-admin app. better-auth 1.7 on its own `nachklang_admin` database (Kysely + mysql2; every
+*Admin module (`src/models/admin/`)* — used by every app: calendar, feedback, tickets and the
+admin app itself. better-auth 1.7 on its own `nachklang_admin` database (Kysely + mysql2; every
 other domain keeps the `mariadb` driver), mounted at `/admin/auth/*` for the auth handler
 and `/admin` for the JSON routes. Sessions are httpOnly cookies scoped to
 `.nachklang.art`, so one sign-in covers every app. Accounts are **invite-only** — public
@@ -59,11 +59,24 @@ two and the last-admin guard stops guarding; and both write endpoints accept
 same at the `access` role. `ADMIN_BOOTSTRAP_EMAIL`
 makes sure someone can always get in on a fresh database.
 
-*Legacy calendar* — unchanged: users need a `@nachklang.art` email, and after activation
-get a session token (30-day window, hash + IP stored in the DB), passed as query
-parameters. Migration is planned but not started: `docs/calendar-auth-migration.md`.
-Credentials for non-user calendar access (`MEMBER_CREDENTIAL`, `CHOIR_CREDENTIAL`,
-`MANAGEMENT_CREDENTIAL`) come from `.env`.
+*The calendar* used to be the exception - its own `users`/`sessions` tables, and a session
+token passed in **query parameters**. That is gone: `docs/calendar-auth-migration.md` records
+the migration, finished 2026-09-06. Writes sit behind `requireAppAccess('calendar')`; reads
+resolve the same cookie optionally, because one URL serves an anonymous visitor, an iCal
+subscription and a signed-in editor.
+
+Two calendar-specific things survive that migration and are easy to break:
+
+- **The `public` calendar answers with no credential of any kind.** nachklang.art reads it to
+  show the next upcoming event. Pinned by `test/calendar/credentials.service.test.ts` and
+  `test/calendar/events.router.test.ts`.
+- **The shared passwords (`MEMBER_CREDENTIAL`, `CHOIR_CREDENTIAL`, `MANAGEMENT_CREDENTIAL`,
+  from `.env`) still open the restricted calendars for reading**, because an iCal client
+  cannot send a cookie. They can never write.
+
+An event's creator is a display name and nothing else - nothing authorises on it. It resolves
+from the admin module's `user.name` when the row carries an admin id, and otherwise from
+`created_by_name`, a snapshot taken before the legacy `users` table was renamed aside.
 
 **Admin database driver:** the admin pool is the **callback-style** `mysql2`, never
 `mysql2/promise`. Kysely's `MysqlDialect` calls `pool.getConnection((err, conn) => ...)`;