[Bccorb]

Closes #432. Part of the v0.19 release (#385).

What

• assertServiceTokenConfig (already the first boot step) logs one warning naming each of REFRESH_TOKEN_LOOKUP_SECRET, TOTP_SECRET_ENCRYPTION_KEY, OAUTH_STATE_SECRET and DECOY_SUBJECT_SECRET that is unset and so falls back to the service token, with what rotating the service token would then break
• docs/production-operations.md gains a section on separating them safely: set each to the current service token value, redeploy, then rotate the service token
• Patch changeset

Deviation from the issue

The issue asked to refuse to boot in production while the TOTP key falls back. I did not, on purpose:

• Every existing deployment relying on the fallback would stop booting on upgrade
• The obvious fix for that refusal, setting a fresh TOTP_SECRET_ENCRYPTION_KEY, makes every stored TOTP secret unreadable, which is the lockout the issue wants to prevent

Each of the four fallbacks uses the service token's raw value exactly as it would its own variable (checked in token.ts, totpService.ts, oauthService.ts, decoyPrincipal.ts), so setting them to the current value first is a no-op and the separation is safe. A warning plus that procedure gets to the same end without stranding anyone. If you still want a production refusal, it belongs in a later release once the warning has been out long enough for operators to act.

The health endpoint flag is left out of this PR to avoid colliding with #444, which reshapes the same response.

Checks

• npm run typecheck: pass
• npm run lint: pass
• npm run format:check: pass
• npm run coverage: 136 files, 1815 passed, 1 todo. Statements 98.9%, branches 95.38%, functions 99.27%, lines 99.14%

[Bccorb]

Updated per review: the fallback stays as a warning in v0.19, now marked deprecated in the warning, the configuration and production docs, and the changeset. Removal, with each secret required whenever its feature is in use, is #447 (v0.20), which also lists the deployment configs to update first.