Phase 2 preflight (npm run supertokens:check) + Phase 0 docs correction

[NeverEndingCode]

Two things, both serving the next step of the SuperTokens rollout.

1. npm run supertokens:check — a Phase 2 deployment preflight

Phase 2 stands up the SuperTokens core, and nothing verified it was configured
correctly. The operator's only feedback was to set AUTH_MODE and watch what
broke — and one failure mode does not break visibly at all: a core running
without API_KEYS will mint a login session for any user id. Because the id
mapping makes session.getUserId() return github:37058311 verbatim, anyone
who can reach that port can mint a session for any SUPER_ADMIN_IDS value
without a request ever touching RackStack. Nothing inside the app would surface
it.

=== SuperTokens deployment preflight ===
[PASS] SUPERTOKENS_CONNECTION_URI    http://192.168.x.x:3567
[PASS] public origin                 https://rackstack.example.com
[PASS] OAuth providers               github, discord
[PASS] github redirect to register   .../auth/callback/github  (register the PARENT path .../auth …)
[PASS] core reachable                answered 200
[PASS] core requires authentication  anonymous request rejected (401)
[PASS] SUPERTOKENS_API_KEY           accepted by the core
[PASS] core has its own database     no SuperTokens tables in RackStack's database

PREFLIGHT: PASS - the deployment side is ready for AUTH_MODE=dual.

Checks, and why each is there:

Check	Otherwise discovered by
Core reachable	The localhost-from-inside-a-container mistake
Core requires authentication	Never — see above
API key accepted	Every login failing the moment AUTH_MODE is set
Core has its own database	Two schemas entangled in backup/rollback
Public origin + providers	The two boot failures in runbook D3

It also prints the exact redirect URLs to register, including why GitHub's is
the parent path — GitHub allows one URL and matches subdirectories, so
registering the SuperTokens path directly breaks every existing login.

Deliberately does not read AUTH_MODE, and does not import
server/db/index.js. The entire value is running it before anything is
switched, so it has to be safe on a box still serving the legacy stack — the
same read-only discipline shadow:check has. Loopback gets the same treatment
init.js gives it: a missing API key is a WARN, not a FAIL, when only this
host can reach the core.

Added to the runbook as B3a, the gate for Part B. shadow:check gates the
data half of the cutover; this gates the deployment half.

2. Phase 0 docs correction (original content of this PR)

The v1.8.1 shadow report named the database it read
(postgres postgresql://rackstack_user@…:5432/rackstack), which confirms v1.7's
Postgres cutover has happened. Both the migration plan and the runbook still
said it was outstanding.

Phase 0 is now fully satisfied.

Verification

• 648 tests SQLite / 674 Postgres, 39 smoke assertions
• 14 new tests: open core FAILs, closed core PASSes, /hello is not used for
  the auth check (it answers unauthenticated by design, so it would read an open
  core as healthy), key mismatch, missing key remote-vs-loopback, shared
  database, unreachable core invents no auth verdict, empty run is not a PASS

No version bump — supertokens:check is additive and unreleased; it ships with
whatever goes out next.

🤖 Generated with Claude Code