chore(deploy): gate Cloudflare Pages production promotion

[zoeyrose]

Summary

Add an explicit, reviewable production-promotion gate for the Cloudflare
Pages site. This is a focused follow-up to #3
and follows the production environment/deployment protection recently added
for Observatory #14.

The protection must fit the website's static, Git-integrated Pages design and
must not create an unreviewed direct-upload or privileged preview path.

Current state

• main is documented as the only production branch for
  https://atrinik.org.
• Non-production branches use Cloudflare's provider-managed pages.dev
  previews; previews are public and must remain credential-free.
• validate.yml validates the site and release.yml publishes releases;
  Cloudflare Pages owns the site deployment path.
• The repository has no GitHub Actions deployment environment at the time of
  issue creation.
• Harden website accessibility, performance, security, deployment, and rollback #3 already covers broad accessibility, performance, security, deployment,
  and rollback hardening; this issue narrows the production approval and
  deployment-control portion.

Requested outcome

Establish and document an effective production protection model so that a
reviewed change and successful validation are required before atrinik.org
is promoted, with a clear non-self approval boundary where the chosen provider
mechanism supports one.

Scope

• Audit the live Cloudflare Pages Git integration, production branch setting,
  deployment history/rollback controls, custom domains, and the repository's
  branch/ruleset/Actions configuration.
• Select the supported protection mechanism for the actual production path.
  Prefer native Pages/provider controls when they can provide an equivalent
  approval gate. If they cannot, document that limitation and use the narrowest
  repository-side control that preserves the native Pages preview model.
• Keep main as the only production source. Pull requests, forks, and
  non-production branches must not receive production credentials or a path to
  publish atrinik.org.
• If a GitHub production environment is genuinely required by the selected
  design, configure a production environment with a main-only branch
  policy, required reviewers, and self-review prevention. Store only a
  least-privilege Pages deployment credential there; never use a broad
  Wrangler OAuth credential.
• Keep native pages.dev previews, the no-custom-preview-domain policy, and
  the no-privileged-preview-workflow constraint.
• Document approval ownership, deployment evidence, rollback, and outage
  behavior in docs/DEPLOYMENT.md and the relevant repository guidance.

Acceptance criteria

• The live production path and its effective protection gate are recorded,
  including the exact branch, reviewer/approval boundary, and provider or
  GitHub settings that enforce it.
• Only reviewed main changes with passing website validation can promote
  the canonical production site; PR, fork, preview, and non-main paths
  cannot do so.
• Any production credential is least-privilege, environment-scoped, absent
  from previews and static output, and documented by name only.
• Deployment history, rollback, approval evidence, and ownership are
  documented and exercised against the selected control path.
• The solution does not add custom preview domains, direct-upload tooling,
  a privileged preview workflow, or production DNS changes as a side
  effect.
• npm ci, npm run check, npm run build,
  npm run deploy:dry-run, and git diff --check pass.

Non-goals

• Reworking the website content or static architecture.
• Replacing Cloudflare Pages previews with a separate deployment service.
• Changing atrinik.org, www.atrinik.org, DNS, or TLS configuration without
  separate explicit authorization.