[ksprptr]

Before deploying

• GOOGLE_ENABLED is now required in apps/api/.env — the API refuses to boot without it. Set
  "true" to keep Drive as it is; "false" needs no Google credentials at all.
• Postgres now defaults to 18. An existing 17 volume will not start under it (FATAL: database files are incompatible with server). Either pin POSTGRES_VERSION=17 or follow
  docs/upgrading-postgres.md — dump, down -v, restore.
• Build the images before step 4 of that guide if the Docker VM is tight: the API build needs
  ~6 GiB and OOMs at 2 GiB, which would strand you after the volume is already gone.

What's in it

• GOOGLE_ENABLED mirrors S3_ENABLED. Off, the Drive section disappears from the sidebar and
  every /storage/drive/* and /google-auth/* route 404s, the public OAuth legs included.
• The kill-switch is enforced in one place. StorageRegistry.resolve() 404s a disabled backend
  and all() omits it, so GET /storage/status lists only what is on — S3 included, which used to
  render a permanently dead "No S3 storage connected" card.
• GoogleEnabledGuard covers the OAuth controller, where there is no registry to go through.
• The OAuth credentials are validated only when enabled, so .env.example requires just the
  switch, same as S3.
• The sidebar renders one section per reported backend, with a "No storage backend available"
  note when there are none; / no longer redirects to a hardcoded drive.
• POSTGRES_VERSION picks the major (17 or 18) and PGDATA is pinned, because the 18 image
  moved its default to /var/lib/postgresql/18/docker and the volume mount would miss it.
• Long guides live in docs/ now; the readme keeps a Documentation section pointing at them,
  and its remaining env lists moved into the .env.example comments.

Verification

• pnpm build, pnpm lint, 242 unit (from 233) and 101 e2e (from 96) pass.
• New coverage: the google config, the provider kill-switch, the registry filtering, and a
  google-disabled e2e that boots with GOOGLE_ENABLED=false and asserts [] statuses, 404s
  everywhere, and no database access.
• Postgres 18 exercised for real: all five migrations applied, the API booted against it and
  /health reported postgres: up.
• The upgrade guide was run through its own compose commands (steps 1–6) on a seeded throwaway
  project: dump, down -v, restore on 18, rows and _prisma_migrations intact, migrate deploy
  finds nothing pending. Step 7's image build OOMs on a 2 GiB VM, hence the note above.
• The failure mode is verified too: 18 over a 17 volume exits without touching the data, and 17
  starts again on the same volume.