Log DEMO_MODE state at startup

[Ho1yShif]

Why

The demo's per-visitor isolation + ephemeral history (PRs #4, #5) is gated on DEMO_MODE being a parse-truthy value in the process environment: 1|true|yes|on, case-insensitive, whitespace-trimmed — quotes are NOT stripped (deeptutor/services/demo/rate_limiter.py:71).

We hit a case where the Render dashboard had DEMO_MODE=true set, the service was redeployed, yet demo history was still shared across visitors and survived redeploys. Root cause was configuration, not code — the process was still seeing demo mode as off — but there was no log line to reveal that, so it looked like the isolation code was broken.

Verified empirically that a quoted value silently fails:

DEMO_MODE=true    -> is_demo_mode() == True
DEMO_MODE unset   -> is_demo_mode() == False
DEMO_MODE='"true"' -> is_demo_mode() == False   # quotes not stripped

What

Add one startup log line in the lifespan handler that prints the raw os.environ["DEMO_MODE"] value and the resolved demo state:

DEMO_MODE raw='true' -> demo mode ENABLED; per-visitor ephemeral history ACTIVE
DEMO_MODE raw=None   -> demo mode disabled; per-visitor ephemeral history OFF (single shared on-disk store)

A dashboard says true vs process sees off mismatch is now visible at a glance in deploy logs.

Scope / safety

• Diagnostics only — no behaviour change.
• Wrapped in try/except so it can never block startup.
• Does not enable demo mode anywhere and does not touch render.yaml (the template intentionally ships DEMO_MODE off so private forks are unaffected).

Verification

• pre-commit run --files deeptutor/api/main.py → ruff, ruff-format, mypy, bandit, detect-secrets all pass.
• Smoke-tested is_demo_mode() for set / unset / quoted values (see table above).

🤖 Generated with Claude Code