Add admin identity module: better-auth, per-app permissions, invitations (#12)

Reviewed-on: #12
Co-authored-by: Patrick Müller <mail@pmueller.me>
Co-committed-by: Patrick Müller <mail@pmueller.me>

CLAUDE.md

@@ -10,6 +10,7 @@ npm run start    # Build and start (tsc && node ./dist/app.js)
 npm run debug    # Start with DEBUG=* environment variable
 npm run test     # Run the vitest suite once with coverage (lcov + testResults/sonar-report.xml)
 npm run test:watch  # vitest in watch mode
+npm run test:integration  # Admin-module tests against a throwaway MariaDB (needs docker or podman)
 ```
 
 Run a single test file:
@@ -19,10 +20,12 @@ npx vitest run test/some.test.ts
 
 ## Architecture
 
-Express.js REST API in TypeScript with a service-oriented layering. Domains: `Calendar` (events, users) and `Feedback` (concert feedback forms, mounted at `/feedback`, backed by its own `FEEDBACK_DB` — see `src/models/feedback/`: public submission flow, admin CRUD, reporting, and a Salesforce newsletter-sync integration).
+Express.js REST API in TypeScript with a service-oriented layering. Domains: `Calendar` (events, users), `Feedback` (concert feedback forms, mounted at `/feedback`, backed by its own `FEEDBACK_DB` — see `src/models/feedback/`: public submission flow, admin CRUD, reporting, and a Salesforce newsletter-sync integration), `Tickets` (mounted at `/tickets`), and `Admin` (identity and permissions, mounted at `/admin`, backed by `ADMIN_DB` — see below).
+
+`src/app.factory.ts` builds the Express app; `app.ts` only starts it. The split exists so the integration tests drive the real wiring.
 
 **Request path:**
-1. `app.ts` mounts `Calendar.router.ts` at `/calendar`
+1. `src/app.factory.ts` mounts `Calendar.router.ts` at `/calendar`
 2. `Calendar.router.ts` delegates to `events.router.ts` and `users.router.ts`
 3. Routers call services; services call the MariaDB pool in `Calendar.db.ts`
 
@@ -35,7 +38,43 @@ Express.js REST API in TypeScript with a service-oriented layering. Domains: `Ca
 | 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:** Users must have a `@nachklang.art` email. After activation they receive a session token (30-day window); the token hash + IP are stored in the DB. Credentials for non-user calendar access (`MEMBER_CREDENTIAL`, `CHOIR_CREDENTIAL`, `MANAGEMENT_CREDENTIAL`) come from `.env`.
+**Auth model:** Two of them, on purpose.
+
+*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
+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
+sign-up is disabled, and `invitations.plugin.ts` is the only code that creates users.
+A permission is **(app, role)** in `user_app_permissions`, keyed on
+`(user_id, app, role)` so one user can hold several roles per app. `access` is the only role
+today and means "may use this app at all"; `APP_ROLES` in `admin.schema.ts` is the contract,
+and a role not listed there is rejected rather than written. `requireAppAccess(app)` in
+`admin.middleware.ts` is the single authenticator - it takes an optional second argument to
+narrow to one role, and queries the database on every request (no cookie cache) so disabling
+a user takes effect at once. Two things to know before touching this: any count of admins
+must count **distinct users**, not permission rows, or a single admin with two roles reads as
+two and the last-admin guard stops guarding; and both write endpoints accept
+`{permissions: [{app, role}]}` as well as the older `{apps: ['tickets']}`, which means the
+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`.
+
+**Admin database driver:** the admin pool is the **callback-style** `mysql2`, never
+`mysql2/promise`. Kysely's `MysqlDialect` calls `pool.getConnection((err, conn) => ...)`;
+the promise wrapper ignores that callback, so every Kysely query hangs forever with no
+error. Only the integration tests catch this.
+
+**Admin schema changes:** `sql/admin/NNN_*.sql`, hand-maintained and mirrored in
+`docker/init/`. The better-auth tables must match what the configured version derives from
+`admin.auth.ts` — on every better-auth upgrade, re-derive them (`getAuthTables` from
+`better-auth/db`, called with `auth.options`), diff, and add a numbered migration. Do not
+use the published `@better-auth/cli`; it lags the library.
 
 **Event versioning:** Events have a companion `event_versions` table. `events.service.ts` manages writes to both.
 
@@ -52,13 +91,31 @@ backslash escapes inside double quotes are expanded. Wrap any value containing `
 surrounding spaces in single quotes (`DB_PASSWORD='abc#def'`), which are taken literally.
 A truncated password shows up as MariaDB "Access denied ... (using password: YES)".
 
+**`NODE_ENV` is load-bearing for the admin module.** Only the explicit values
+`development` and `test` relax anything; everything else, *including unset*, is treated as
+production (strict secrets, cross-subdomain cookies, no localhost CORS). That direction is
+deliberate: a Plesk vhost does not set `NODE_ENV`, and the inverse arrangement would
+silently degrade the signing key, the cookie domain and the CORS list at once. Local work
+needs `NODE_ENV=development`.
+
 Copy `.env.example` (or create `.env`) with:
 ```
+NODE_ENV=
 PORT=
 DB_HOST=
 DB_USER=
 DB_PASSWORD=
 CALENDAR_DB=
+ADMIN_DB=
+BETTER_AUTH_SECRET=
+API_BASE_URL=
+ADMIN_APP_URL=
+APP_ORIGINS=
+PASSKEY_RP_ID=
+ADMIN_BOOTSTRAP_EMAIL=
+CLIENT_IP_HEADERS=
+TRUSTED_PROXY_IPS=
+ADMIN_LOG_INVITE_LINKS=
 FEEDBACK_DB=
 FEEDBACK_IP_SALT=
 FEEDBACK_RATE_LIMIT_MAX=