Require an explicit Cloud integration decision before merge

[sdairs]

Parent and dependencies

• Follow-up to Make live Cloud integration CI selective, on-demand, and resilient #403.
• Depends on Make live Cloud integration CI on-demand and globally serialized #404 and Add scoped manual Cloud integration runs #405.
• The automatic no-suite decision depends on Select live Cloud integration suites from affected API domains #406.

Context

#404 intentionally keeps on-demand Cloud Integration informational. The run-cloud-integration label starts an exact-SHA live run, but main currently has no required status checks. A reviewer can therefore approve and merge a PR without anyone applying the label or running live Cloud CI.

The on-demand model still needs an enforced decision point. A PR should not silently bypass live validation merely because a maintainer forgot the label.

Proposed operating model

Add one stable required check named Cloud integration decision for every PR head SHA. It passes only when one of these outcomes is recorded for that exact SHA:

1. The selected Cloud Integration suites completed successfully.
2. The Select live Cloud integration suites from affected API domains #406 planner selected no relevant live suites, without entering the environment-bearing job.
3. A maintainer explicitly applied a one-shot Cloud CI override.

Otherwise the check remains pending or fails with instructions to apply run-cloud-integration or use the override. A later push creates a new head SHA and must invalidate every earlier run and override.

Make Cloud integration decision a required main status check only after the controller is available on the default branch, so enabling protection cannot lock every PR. Keep the live workflow itself on-demand.

Override semantics

• Provide an explicit maintainer-only override, provisionally skip-cloud-integration.
• Bind the override to the head SHA captured by its event; a later push must not inherit it.
• Record the actor, SHA, timestamp, and reason or linked stack run in the check output or workflow summary.
• Leave a clear audit trail on the PR.
• An unrelated label must never satisfy the required check.
• Removing and reapplying a one-shot override is required to waive a newer SHA.

The implementation may use a label, a scoped manual dispatch, or another trusted control, but it must preserve these authorization and SHA-binding properties.

Security model

• Do not give untrusted PR code a write-capable status controller token.
• A trusted workflow_run, metadata-only pull_request_target, GitHub App, or equivalent controller may update the decision check. A pull_request_target controller must never check out or execute PR code.
• Keep live PR execution on pull_request, same-repository only, with the Dependabot exclusion from Make live Cloud integration CI on-demand and globally serialized #404.
• Fork PRs must not receive Cloud secrets; they require a maintainer mirror or explicit override.

Stacked PR behavior

A manual all run on the top branch validates the combined stack snapshot but does not naturally create successful checks on lower PR heads. Define and document one of these explicit policies:

• Run affected suites independently on every PR.
• Use SHA-bound overrides on lower PRs that identify the successful top-stack run covering them.
• Have a trusted controller attest the successful top-stack run to verified ancestor PR SHAs.

Do not silently treat a top-stack run as covering lower PRs without recording that decision on each lower SHA.

Non-goals

• Making live tests automatic on every push.
• Retry, timeout, cleanup, caching, or live-test identity changes.
• Allowing a persistent label to waive future commits.
• Executing PR code from pull_request_target.

Acceptance criteria

• An affected PR cannot merge while its current head has neither a successful Cloud run nor an explicit override.
• A successful live run satisfies the required decision only for the exact tested SHA.
• A failed live run keeps the decision failing unless a subsequent explicit override is recorded.
• A Select live Cloud integration suites from affected API domains #406 no-suite result satisfies the decision without entering the secret-bearing job.
• A new commit invalidates a previous success, no-suite decision, or override.
• Only maintainers can override, and the actor and exact SHA are auditable.
• Unrelated labels, skipped admission jobs, stale workflow runs, and fork events cannot accidentally produce success.
• Cloud integration decision is required by main branch protection after rollout.
• Ordinary build, unit, clippy, and formatting CI behavior remains unchanged.
• Stacked-PR coverage and override behavior is documented for maintainers.