fix(api): session cookie never issued over HTTP; ship the seed script

Prod came up with nobody able to log in, in two separate ways.

1. No sign-in account exists. `prisma migrate deploy` creates tables, never
   rows, and nothing in the deploy path seeds one — deliberately, since making
   an administrator should not be a side effect of shipping code. But
   apps/api/scripts was not in the runtime image either, so the only way to
   create the first account was to run the script from a developer machine
   against a production DATABASE_URL. Ship scripts/ in the image so it can be
   run on the host with docker exec. Still never run automatically.

2. Login could not establish a session at all. cookie.secure followed NODE_ENV,
   the image sets NODE_ENV=production, and the app is served over plain HTTP —
   express-session then silently emits NO Set-Cookie header. POST /auth/login
   still answered 200 with the full user object, no session was created, every
   later request 403'd, and the UI would have looped back to /login. It reads
   as an auth bug and is really a transport mismatch.

   The flag is now driven by SESSION_COOKIE_SECURE, still defaulting to
   NODE_ENV. An EMPTY value counts as unset rather than false, because compose
   turns an absent `${SESSION_COOKIE_SECURE:-}` into the empty string and the
   naive check would have quietly dropped Secure on any deployment that merely
   passed the variable through.

   galactus sets it to "false". That is acceptable ONLY because the host is
   reachable exclusively over Tailscale, so WireGuard already encrypts the
   wire. It must go back to "true" when the app is served over TLS or exposed
   off-tailnet; behind a TLS-terminating proxy, set trust proxy instead.

Verified against live prod: seeded an admin, POST /auth/login returns 200 with
full ADMIN abilities, a wrong password is rejected with 401, and no Set-Cookie
was present before this change.

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

docs/DEPLOY_AND_MIGRATIONS.md

@@ -192,6 +192,46 @@ Still open, and **not** handled by anything in this repo:
 - The channel to the VPS crosses the public internet. It needs a tunnel or TLS —
   do not publish raw 3306.
 
+## Seeding the first sign-in account
+
+A freshly migrated database has a schema and **no users**, so nobody can log in.
+`prisma migrate deploy` creates tables, never rows; nothing in the deploy path
+seeds an account, by design — creating an administrator should be a deliberate
+act, not a side effect of shipping code.
+
+`apps/api/scripts/seed-user.mjs` ships inside the API image. On the target host:
+
+```bash
+docker exec -e SEED_PASSWORD='<a strong password>' \
+  <api-container> node apps/api/scripts/seed-user.mjs
+```
+
+Defaults are `admin@jorgecuadros.local` / `ChangeMe!2026` / role `ADMIN`,
+overridable with `SEED_EMAIL`, `SEED_PASSWORD`, `SEED_NAME`. **Do not accept the
+default password on anything but a dev database** — it is published in this
+repo's README. The script upserts by email, so re-running is safe, but it also
+**resets the password of an existing account**.
+
+## The session cookie and TLS
+
+`SESSION_COOKIE_SECURE` controls the `Secure` flag on the session cookie. It
+defaults to on in production, and it must be explicitly `"false"` for a
+deployment served over plain HTTP.
+
+This is not cosmetic. express-session silently declines to emit a `Secure`
+cookie over an unencrypted connection: no `Set-Cookie` header is sent at all,
+`POST /auth/login` still answers `200` with the user object, no session is
+established, every subsequent request gets `403`, and the UI bounces back to
+`/login` in a loop. It looks like an auth bug and is really a transport
+mismatch.
+
+galactus runs with `SESSION_COOKIE_SECURE=false`, which is acceptable **only**
+because it is reachable exclusively over Tailscale — WireGuard already encrypts
+the wire, so the cookie never crosses an untrusted network. Turn it back on the
+moment the app is served over TLS or reachable off-tailnet. Behind a
+TLS-terminating reverse proxy, set `trust proxy` on the Nest app instead of
+disabling the flag.
+
 ## Known caveats in the deploy path
 
 - The pre-migrate backup step sets `NODE_TLS_REJECT_UNAUTHORIZED=0` because