feat(config): warn at boot when one secret serves several purposes #432

Why

When the dedicated secrets are unset, the service token (SEAMLESS_SERVICE_TOKEN, or API_SERVICE_TOKEN) is also the refresh token lookup key, the TOTP secret encryption key, the OAuth state key and the decoy subject key. The server adapter holds the same token. Rotating it after a leak then breaks every refresh token and every TOTP enrollment, which is a lockout.

What

• Log a warning at boot naming each secret that falls back to the service token, and show it on /health/status
• In production, refuse to boot while the TOTP encryption key falls back to the service token, unless explicitly allowed
• Document the rotation story per secret in docs/production-operations.md

Done when

An operator can see which secrets are shared, and can rotate the service token without losing TOTP or refresh tokens.