Limit manual production deploys to maintainers

[demegire]

What and why

Write access now lets teammates (starting with our intern hamitarsln) push branches to staging and test there without approval. That access must not reach production.

• Merges: a new ruleset, "Main: only maintainers merge" (already active), lets only tin-lite-maintainers update main.
• Manual deploys: this PR closes the remaining gap. deploy's Run workflow (a prod redeploy or rollback) now refuses anyone not in the PROD_DEPLOYERS repository variable (set to the four maintainers; only admins can change it). Merges still reach production automatically through ci.
• Docs: docs/staging.md and docs/repository-policy.md describe the setup.

Verification

• The allowlist check, run on its own: a maintainer is allowed; hamitarsln, a prefix of a listed name (ege vs ege-em), and an empty list are refused; CI-triggered runs are unaffected.
• The workflow YAML parses.

Tested on staging

Workflow and docs only; nothing that runs on the VM changes. Deployed to staging by pushing to staging, which also satisfies the required check.

🤖 Generated with Claude Code

[demegire]

Follow-up from a security review of the first commit. github.actor keeps the original actor on a re-run, so a writer could have re-run an old deploy, or only its failed production job, and put an older commit on prod.

Now:

• manual runs and all re-runs check github.triggering_actor against PROD_DEPLOYERS, in the release job and again as the production job's first step, before it gets credentials;
• an automatic deploy only ships main's current tip. An older one skips cleanly in the release job, and the production job refuses it.

Rollbacks are a maintainer's Run workflow with the SHA.

Checked: an intern re-running an old automatic or manual deploy is refused; a maintainer's manual deploy or re-run, and the first automatic run after a merge, are allowed.