Add a staging deployment that cannot touch production's state

[demegire]

What

A staging deployment at https://app.staging.tin.computer, so a change can run end to end the way production runs it before it reaches app.tin.computer. See docs/staging.md.

• code.storage repo prefix. TIN_LITE_CODE_STORAGE_REPO_PREFIX (staging: staging-) applies wherever Tin names a repository upstream: lookup, create, delete, sandbox git remotes and scoped tokens. Stored references keep the unprefixed ID. Staging shares production's organization but writes staging-registry/workflows, staging-wiki/system and staging-projects/<id>.
• Boot guard. TIN_LITE_ENVIRONMENT=staging refuses to start without a prefix, outside Stripe test mode, or on production's database host or Temporal namespace (compared case-insensitively against TIN_LITE_PRODUCTION_*, set on staging only).
• Deploy target. infra/deploy.sh takes TIN_LITE_DEPLOY_TARGET (prod by default, behaviour unchanged). Staging keeps its release env on the host (/etc/tin-lite/release.env), so nothing is uploaded from a workstation, and runs tin-lite migrate from the new release before switching.
• deploy-staging workflow. Every push to main, and any ref on request, through workload identity. Google trusts only this repo's staging environment, and the deployer can log in to the staging host only.
• Staging Postgres. infra/install_staging_postgres.sh installs 18.6 on the staging host with production's relevant settings. tests/test_sql_requires_where.py stands in for production's pg_strict (no DELETE/UPDATE without WHERE); the current SQL passes.

Verified

• Deployed this branch to staging with TIN_LITE_DEPLOY_TARGET=staging infra/deploy.sh. All 63 migrations applied to the fresh database, the catalog synced, and /healthz returns 200.
• Staging's catalog and wiki were written to staging-registry/workflows and staging-wiki/system.
• The Temporal worker polls the staging namespace.
• Focused tests: test_staging_isolation, test_sql_requires_where, test_secret_fences, code-storage and settings tests.

Not verified yet

• The Actions workflow itself. workflow_dispatch needs the file on main, so its first run is the merge of this PR.
• Sign-in, MCP, GitHub App install, Stripe test top-up and a Start here run on staging. These need the app.staging.tin.computer DNS record, which isn't live yet.

Risk

Production's deploy path is unchanged unless TIN_LITE_DEPLOY_TARGET is set. Staging's code.storage key is organization-wide, a known trade-off documented in docs/staging.md.

🤖 Generated with Claude Code