Read calendar event creators from the admin module, and archive the old ones

Steps 1 and 3 of docs/calendar-auth-migration.md. The calendar is the last
module still authenticating against its own users/sessions tables; this is
the groundwork that lets step 4 swap it for the shared admin identity.

An event now records its creator twice: created_by_id, the legacy INT into
the calendar database's own users table, and created_by_user_id, the admin
module's VARCHAR(36) id. The two live in different databases, so there is no
foreign key and no join - a cross-schema reference would tie the schemas'
lifecycles together, and the name is instead resolved through one lookup per
result set against the admin database.

The creator is only ever rendered as a name; nothing authorises on it. That
is what makes the planned account backfill unnecessary - dropped by decision -
and what makes the read degrade rather than fail: an admin id that no longer
resolves falls back, and an unreachable admin database costs a name rather
than the response. The public calendar is read anonymously by nachklang.art
and has never depended on the admin database being up.

Since there is no backfill, step 5 dropping the legacy users table would have
erased the authorship of every pre-cutover event. Migration 002 brings that
part of step 5 forward and snapshots the names onto the events themselves, so
the data is safe well before the table holding it goes away.

The same SELECT and row mapper existed in four copies; collapsed to one of
each first, so the dual read is written once rather than four times.

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

sql/calendar/001_add_admin_user_bridge.sql

@@ -0,0 +1,38 @@
+-- Nachklang e.V. Calendar module — step 1 of docs/calendar-auth-migration.md.
+-- Adds the bridging columns that let an event record who created it as an
+-- *admin* user id (VARCHAR(36)) alongside the legacy calendar users.user_id
+-- (INT). Apply manually against the CALENDAR_DB database:
+--   mysql -h <DB_HOST> -u <DB_USER> -p <CALENDAR_DB> < 001_add_admin_user_bridge.sql
+--
+-- Numbered 001 because this is the first migration this repo owns for the
+-- calendar schema: the tables themselves predate it and were provided by the
+-- repo owner (mirrored for dev in docker/init/01-calendar-schema-dev.sql).
+--
+-- Nothing reads these columns yet — step 3 introduces the dual-read. Adding
+-- them first means the backfill in step 2 has somewhere to write, and this
+-- migration can be applied to production on its own without any code change.
+--
+-- No foreign key, on purpose. The admin `user` table lives in a *different*
+-- database (nachklang_admin) behind a different connection pool, and a
+-- cross-schema FK would tie the two schemas' lifecycles together: you could no
+-- longer dump, restore or move one without the other. The reference is
+-- enforced in application code, which is also where the legacy/new fallback
+-- lives.
+--
+-- The collation is pinned to the admin database's (utf8mb4_unicode_ci) rather
+-- than inherited from the calendar tables' utf8mb4_general_ci. These columns
+-- hold ids that only ever compare against nachklang_admin.user.id, and a
+-- mismatched collation makes any such comparison fail at runtime with
+-- "Illegal mix of collations" instead of at review time.
+
+ALTER TABLE `events`
+    ADD COLUMN `created_by_user_id` VARCHAR(36)
+        CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
+        NULL DEFAULT NULL AFTER `created_by_id`,
+    ADD KEY `events_created_by_user_idx` (`created_by_user_id`);
+
+ALTER TABLE `event_versions`
+    ADD COLUMN `version_created_by_user_id` VARCHAR(36)
+        CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
+        NULL DEFAULT NULL AFTER `version_created_by_id`,
+    ADD KEY `event_versions_created_by_user_idx` (`version_created_by_user_id`);

sql/calendar/002_snapshot_legacy_creator_names.sql

@@ -0,0 +1,42 @@
+-- Nachklang e.V. Calendar module — step 5 preparation, brought forward.
+-- Apply manually against the CALENDAR_DB database, after 001:
+--   mysql -h <DB_HOST> -u <DB_USER> -p <CALENDAR_DB> < 002_snapshot_legacy_creator_names.sql
+--
+-- Snapshots the creator's and last editor's *name* onto the event itself.
+--
+-- Why: the creator is only ever rendered as a name (nothing authorises on it),
+-- and today that name comes from joining the calendar's own `users` table.
+-- Step 5 drops that table, which would silently erase the authorship of every
+-- event created before the cutover. There is no account backfill to save them
+-- either - that was dropped deliberately, see docs/calendar-auth-migration.md.
+-- One text column per reference keeps the history at no ongoing cost.
+--
+-- These columns are an archive, not a source of truth. Nothing writes them
+-- after this backfill: events created from the cutover onwards carry an admin
+-- user id, whose name is resolved live so that renaming an account updates
+-- everywhere. The read path prefers the live admin name, falls back to this
+-- snapshot, and falls back again to the join until step 5 removes it.
+--
+-- The backfill is written to be idempotent (`WHERE ... IS NULL`) so it can be
+-- re-run. Step 4's migration does exactly that, to catch anything created
+-- between this migration and the cutover.
+--
+-- No charset clause: unlike 001's id columns these hold display text that is
+-- only ever compared against other calendar data, so they inherit the tables'
+-- utf8mb4_general_ci like the columns they are copied from.
+
+ALTER TABLE `events`
+    ADD COLUMN `created_by_name` VARCHAR(255) NULL DEFAULT NULL AFTER `created_by_user_id`;
+
+ALTER TABLE `event_versions`
+    ADD COLUMN `version_created_by_name` VARCHAR(255) NULL DEFAULT NULL AFTER `version_created_by_user_id`;
+
+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;