Deploy Railway staging/demo profiles with health and secret checks

Outcome

One public single-process service runs the selected auth profile, SQLite volume, APIs, webhooks, dispatcher, and consoles with profile-aware configuration.

Scope

• Build and deploy FastAPI plus static consoles as one Railway service.
• Attach a persistent volume and enforce one replica/worker.
• Configure local, staging, and demo profiles with fail-fast placeholder/missing-secret checks, including separate OAuth/session keys, vault KEK, and receipt/content HMAC key.
• Add non-secret health checks for database, schema, auth/JWKS, adapters, Stripe webhook, effect/projector readiness, and HMAC key version without exposing values.

Acceptance

• Public profiles refuse relaxed authentication and placeholder secrets.
• Secret values are entered by the product owner in Railway, never GitHub or model context.
• Demo uses Duffel/Stripe test modes and real auth; staging may use stubs.
• Health output names missing keys/versions but never values.
• A planned effect survives process restart and is dispatchable from the volume-backed input row.
• Redeploy downtime and no-deploy rehearsal/demo windows are documented.

Dependencies

• #2, #19, #21, #24, #25, and security gate #22.

Review

Deployment/security review plus product-owner secret-entry evidence.

Start with the FastAPI service, profile-aware configuration, Railway deployment, persistent-volume setup, health checks, and dispatcher entry points; review dependencies #2, #19, #21, #24, #25, and security gate #22 first. Done means the acceptance checks pass, secret values remain outside GitHub and model context, restart dispatch works, and redeploy/demo procedures are documented and reviewed.