chore(governance): authorize Cloudflare Git access for metaserver-worker

[zoeyrose]

Parent initiative: atrinik/metaserver-worker#53

Outcome

Authorize and record the minimum GitHub-side access needed for Cloudflare
Workers Builds to connect atrinik/metaserver-worker, while preserving the
working atrinik/website Pages connection and the organization's
selected-repository GitHub App policy.

Record the reviewed delivery decision that protected main is the metaserver's
sole production branch: merging a pull request into main authorizes Workers
Builds to start routine production delivery automatically. Do not add a second
production branch, GitHub Actions environment approval, release/tag gate,
Deploy Hook secret, or privileged workflow dispatch for ordinary deployment.

The organization already has the Cloudflare Workers and Pages GitHub App in
selected-repository mode and the website produces live Cloudflare checks. The
metaserver is not connected today. Exact selected access must be verified by
an organization owner in the GitHub App UI; do not infer it from the app's
organization-wide event subscription.

Desired governance contract

• Inventory the stable Cloudflare App and installation identities, exact
  permissions and subscribed events, selected repositories, accountable
  owner, intended consumers, verification/review date, revocation procedure,
  and evidence location without recording a private key, installation token,
  API token, Deploy Hook URL, webhook secret, or credential value.
• Add only atrinik/metaserver-worker to the existing selected-repository
  installation when the repository-side production and preview contracts are
  reviewed. Preserve atrinik/website; add no unrelated repository and do not
  broaden the installation to all repositories.
• Preserve main as the default, pull-request-only protected branch. Its
  accepted push event is the provider's automatic production trigger; direct
  pushes, force pushes, and deletion remain prohibited by existing governance.
• Record that exceptional migration/control-plane handling retries an exact
  current main SHA through the provider and is not a bypass of pull-request
  or branch policy. It must not introduce a second long-lived branch.
• Distinguish the provider App from a GitHub Actions deployment credential.
  Workers Builds should publish its own checks/deployments/pull-request
  feedback; no repository Actions secret or environment is required merely to
  duplicate that integration.
• Decide and document how an owner-installed external CI/deployment App fits
  config/manual-settings.json. The existing repository-scoped App schema is
  oriented around Apps consumed by Actions; extend its value-free contract and
  validation where appropriate, or record a narrow, reviewed external-provider
  ownership model instead of misclassifying the installation.
• Preserve least privilege, owner-only installation changes, reviewable manual
  UI steps, and a read-only verification path. Never claim that metadata
  verifies effective token contents or runtime Cloudflare permissions.

Acceptance criteria

• Desired state records the exact App/installation/repository identities,
  permissions, event set, owner, purpose, verification cadence, and
  disconnection/revocation runbook with no credential values.
• The contract records main as the sole automatic production branch and
  the reviewed PR merge as routine authorization, with no extra production
  branch, Actions environment approval, release gate, Deploy Hook secret,
  or workflow dispatch.
• Existing default-branch governance still requires pull requests and
  rejects direct pushes, deletion, and non-fast-forward updates; automatic
  Cloudflare delivery does not add a bypass actor or weaken those rules.
• Validation rejects identity drift, missing intended selected access,
  accidental all-repositories access, unrelated selected repositories, or
  loss of the existing website selection.
• The publisher/verification plan is reviewed before any live change and
  contains no unrelated governance mutation or policy relaxation.
• A separately authorized organization-owner step grants the App access to
  atrinik/metaserver-worker only after the repository contracts are ready;
  readback then proves the website and metaserver selections and no others
  were changed.
• The metaserver's Cloudflare check/deployment producer is documented
  without making the post-merge production check a pull-request merge gate
  or adding it to GitHub Actions bypass policy. Any distinct pre-merge
  review check from Atrinik work synchronization is stale #55 is governed only after its stable name and failure
  behavior are observed.
• bin/validate, affected manual-settings validation/tests, the relevant
  publisher plan, and git diff --check pass. No --apply or owner UI
  mutation occurs as part of the implementation pull request.

Coordination

Provider-side connection and initial automatic-main proof remain owned by
atrinik/metaserver-worker#56. Repository deployment
semantics remain owned by
atrinik/metaserver-worker#54. This issue owns only
GitHub organization desired state and the separately authorized
selected-repository App change.