fix(deploy): report and gate on whether the app can sign anyone in

[kunjhirapara]

verify-rollout checks that the VM is serving the commit that was built. It does not check that the commit works, and for this rollout those are very different things.

The image that switches sign-in to Auth.js can reach the VM before anyone sets the Auth.js environment variables. Nothing looks broken from outside: the app boots, serves every page, and /api/health returns "healthy" — because its integration flags all predate Auth.js and check Clerk-era variables. The only symptom is that nobody can log in, and the deploy that caused it is green.

Publishing was not shipping; shipping is not working. Same lesson, one step further along.

What changes

• /api/health reports integrations.auth.
• verify-rollout fails on it, but only after confirming the rollout itself — so it stays one clear failure at a time.

Details worth checking

The flag is a bare boolean, on purpose. This endpoint is public — the container healthcheck polls it with no session — and publishing the names of the secrets a deployment is missing is a map for anyone probing it. The names go to the container log instead, where an operator can act on them.

Five variables count as required: AUTH_SECRET, AUTH_ADAPTER_SECRET, and the three AUTH_JWT_* values. Deliberately not the OAuth client IDs — a deployment with no Google app is degraded rather than broken, since credentials and magic-link sign-in still work. Firing this flag for something a user can work around would make it mean less when it fires for something they cannot.

Two things that would have made the check useless, both fixed here:

1. jq's // operator treats false as unset, so .integrations.auth // empty returns empty for auth: false — precisely the case being checked — and the gate would have passed silently. It now tests for the key explicitly.
2. An image built before this change has no auth field at all. That reads as empty and is deliberately not a failure: an old image has no opinion, and failing on it would block the very rollout that introduces the flag.

Verification

• 256/256 tests pass (6 new), tsc --noEmit clean, production build green.
• Workflow YAML parses; the embedded script passes bash -n.
• The sed fallback was exercised against three payloads: an old image with no auth key → empty (passes), auth:false → false (fails), auth:true → true (passes).

Note on the current Deploy failure

This does not make the failing check on main pass. That failure is correct — production is still serving 1d98fb9 because commit-watchtower does not exist, which was measured over a full poll interval. The fix for that remains the whole-stack docker compose pull && docker compose up -d on the VM.

Right now that failing check is the only thing stopping b8a4601 from reaching users without the AUTH_* variables set. Set them before the redeploy.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.