Move the calendar onto the shared session cookie

Step 4 of docs/calendar-auth-migration.md, and the close of
DEFERRED_SECURITY.md item 1: no calendar route reads sessionId/sessionKey from
the query string any more, so a live credential no longer travels through
access logs, browser history and Referer headers.

The four write routes sit behind requireAppAccess('calendar'), which also
narrows who may edit from "any activated @nachklang.art account" to an
explicit per-user permission. They answer 401 signed out and 403 without the
permission, where they previously answered 403 for both.

The three read routes cannot use the middleware: one URL serves an anonymous
visitor, an iCal subscription holding a shared password, and a signed-in
editor who should see drafts. They resolve the session optionally instead, and
a signed-in user without the calendar permission is treated as anonymous
rather than refused - so they keep the public calendar access anyone has.

That public calendar staying anonymous is load-bearing: nachklang.art reads it
to show the next upcoming event. It is now pinned at both the password-table
and the route level, and so is the rule that a shared password can never be
used to write.

credentials.service.ts loses its session half and becomes the password table
it always wanted to be. The shared passwords survive only for iCal clients,
which cannot send a cookie.

Writes record the author as an admin user id and no longer have a legacy int
to write, which is what migration 003 makes room for.

/calendar/users/* is left in place: nothing calls it and a session it mints
opens nothing, but they are still live password-accepting endpoints, so
removing them belongs with the rest of the legacy path in step 5.

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

sql/calendar/003_allow_null_legacy_creator.sql

@@ -0,0 +1,32 @@
+-- Nachklang e.V. Calendar module — step 4 of docs/calendar-auth-migration.md,
+-- the cutover. Apply manually against the CALENDAR_DB database, after 002,
+-- and BEFORE deploying the API build that goes with it:
+--   mysql -h <DB_HOST> -u <DB_USER> -p <CALENDAR_DB> < 003_allow_null_legacy_creator.sql
+--
+-- From the cutover on, an event's creator is an admin-module user id. There is
+-- no legacy calendar user id to write any more, and `events.created_by_id` is
+-- NOT NULL - so without this the very first event created after the deploy
+-- fails to insert. `event_versions.version_created_by_id` is already nullable.
+--
+-- The foreign key to `users` is kept: it permits NULL, so it costs nothing
+-- until step 5 drops the column and the table together.
+--
+-- Applying this early is harmless. Widening a column to accept NULL cannot
+-- break the running pre-cutover build, which always supplies a value, so this
+-- can go out ahead of the deploy rather than during it.
+
+ALTER TABLE `events`
+    MODIFY COLUMN `created_by_id` INT(11) NULL DEFAULT NULL;
+
+-- Re-run of 002's backfill, to catch anything created between the two
+-- migrations while the legacy path was still writing events. Idempotent by
+-- construction: it only touches rows that have no snapshot yet.
+UPDATE `events` e
+    JOIN `users` u ON u.user_id = e.created_by_id
+    SET e.created_by_name = u.full_name
+    WHERE e.created_by_name IS NULL;
+
+UPDATE `event_versions` v
+    JOIN `users` u ON u.user_id = v.version_created_by_id
+    SET v.version_created_by_name = u.full_name
+    WHERE v.version_created_by_name IS NULL;