Harden deployment: configurable Postgres TLS, auth logging, multi-audience verify

[akumar-99]

Fixes surfaced by a real self-hosted production deployment (RDS + Cloudflare mTLS + Google Chat). See the three highest-impact issues from that setup.

Fix 1 — Postgres TLS is configurable, libpq-compatible by default 🔴

The driver now resolves the ssl option itself instead of letting node-pg interpret sslmode. Recent pg treats sslmode=require as verify-full, which rejects managed databases (RDS/Cloud SQL/Neon/Supabase) using a private CA → SELF_SIGNED_CERT_IN_CHAIN crash-loop on first boot.

• Default: require = encrypt-without-verify (what libpq/psycopg/JDBC/pgx all do)
• DB_SSL=verify-full + DB_SSL_CA=/path/ca.pem for strict verification
• DB_SSL=disable to turn TLS off
• A cert error now prints the exact fix instead of crash-looping

Fix 2 — request + auth-failure logging 🔴

/chat/events was a black box: a bad token returned a bare 401 and logged nothing, so "app not responding" was undebuggable. Now it logs every arrival (type=…) and, on rejection, the concrete reason — missing header / aud mismatch: got X, expected Y / issuer mismatch / signature — from decoded claims, never the token.

Fix 3 — verifier accepts project number or app URL audience 🟡

Google Chat's "Audience" can be the project number or the app URL. The verifier hard-coded project-number-only, so an app-URL token was rejected even when correctly configured. It now accepts a list; the dashboard audience field takes a number and/or an https URL (space-separated).

Testing

• New unit tests: SSL resolver mapping, JWT claim decode + failure classification, multi-audience verifier, 401-reason logging.
• Real TLS repro against a self-signed-cert Postgres: old raw sslmode=require fails (DEPTH_ZERO_SELF_SIGNED_CERT), new default connects, verify-full rejects without a CA and connects with DB_SSL_CA.
• Full suite 111 passed on SQLite and over TLS via Repo.postgres.
• Docs updated (.env.example, configuration, server-setup).

Not in this PR

• Fix 4 (GHCR public): there is no REST endpoint to flip container-package visibility — it's a one-time UI toggle by an org owner (asyncup-dev → Packages → asyncup → Package settings → Change visibility → Public).