v1.8.4: dual mode would have refused to start against a good core

[NeverEndingCode]

Caught with the deployment one step away from AUTH_MODE=dual.

v1.8.3 fixed the wrong-endpoint probe in the preflight and left a second
copy of it in the boot path. That copy still used /recipe/users/count,
which SuperTokens core 12 does not implement, and
assertCoreRejectsAnonymous throws on anything that is not a 401 — so the
404 would have been read as "the core is running without API_KEYS" and stopped
the container from starting.

In the preflight the same bug printed an alarming line. Here it would have
blocked the cutover outright and blamed the operator for a URL this code got
wrong — against a core the preflight had just confirmed answers 401
correctly:

[PASS] core requires authentication  anonymous request rejected (401)

The fix

The root cause was duplication, so the fix is de-duplication. The probe now
lives in server/supertokens/coreProbe.js and both callers import it. A test
asserts exactly that — neither file may hardcode a probe path of its own —
because "remember to update both" is precisely what failed here.

The boot guard also narrows when it throws. Only a confirmed-open core is
fatal: a known endpoint answering an unkeyed request with 200. A 404, an
unexpected status, or an unreachable core all warn and let the boot proceed. A
guard on the startup path should refuse only on evidence, never on the absence
of it.

Verification

• 662 tests SQLite / 688 Postgres, 39 smoke assertions
• New regressions: all-404 boots (unverified) rather than throwing; the
  tenant-scoped path is found on a modern core; and both callers are asserted
  to import the shared probe

🤖 Generated with Claude Code