ci: native-live gate shape, post-merge build-gate, release ARM on the protected runner, secret scan - #640

scripts/ci_docs_only.py classifies every non-pull_request event as code (a
documentation-only push now runs the proofs) and keeps the pull_request output
unchanged. ci-post.yml drops its classifier job, keeps the proof jobs, and uses
one canonical all-success aggregate, build-gate, with no name field and no
workflow or job environment; the four leg gates (build-release-gate,
build-debug-gate, kernel-only-gate, sanitizers-gate) become guarded optional
override jobs and are not required contexts. The branch ruleset must require
build-gate instead of build in the same change as the merge. The preflight pins
and release-gate tests follow, with rows that refuse a restored classifier job, a
pull_request trigger and every omitted aggregate need.

docs/ci.md replaces these sentences, quoted from the page:
"The existing docs-only classification still skips proof jobs on a
documentation-only PR or main push."
"Scheduled and manual runs execute every profile."
"A push to `main` follows the same rule, since nothing downstream needs the
proof jobs to have run on a merged commit:"
"`release.yml` starts only on a manual dispatch and builds and verifies its own
tarballs, `promote-baseline.yml` starts on the push to `main`, resolves"
"A documentation merge therefore does not rebuild; the `ci.yml` run on its
commit is `preflight` and the skip."
"That run is `main`'s latest, the one the README badge shows, so after a
documentation merge the badge reports the documentation guards, and the last"
"Shard jobs and leg aggregates skip together only on classified docs-only
changes."
It also replaces the sentences beginning: The existing docs-only classification;
Both preflight tiers together; Scheduled and manual runs execute; ci.yml
retains authorization and draft event handling; Docs-only and GitHub-only
changes; Failed, cancelled or unclassified work; The seven ci-post.yml light
jobs; The full post call graph expands; A push to main follows; A
documentation merge therefore; That run is main's latest; The
ci-workflow-contract stage pins; Shard jobs and leg aggregates. The post
runner-table fragment Seven light jobs becomes Six light jobs.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
(cherry picked from commit 0b12827)

The first commit of this change said the branch ruleset must require build-gate
instead of build, and docs/ci.md said the ruleset changes with the rename. Both
are wrong: the engine's merge ruleset requires only pineforge/verify and
pineforge/parity, ci-post.yml runs only on push, schedule and dispatch, and its
contexts never appear on a pull request head. Acting on that sentence would block
every pull request. docs/ci.md now says so, on the same two lines. No ruleset
change is needed or wanted for this change.

docs/ci.md replaces the sentences beginning: "The required aggregate context is
`build-gate` (formerly `build`); the ruleset changes with that rename."

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
(cherry picked from commit 40ce866)

release.yml prebuilt moves its linux-aarch64 row from hosted ubuntu-22.04-arm to
the bare protected scalar gkp-8cpu-16gb-arm64 (runner group gke-protected,
main-ref workflows only) and runs under the release environment. Both triples,
the x86_64 runner, the release needs and tag assertions, and the upload
safeguards are unchanged; the Build step now uses the runner's core count
instead of -j 4. The preflight pins and regression rows follow.

docs/ci.md replaces sentences beginning: "Hosted exceptions cover PR light jobs
and the existing hosted release cells", "GKE jobs carry no deployment secrets"
and "Release's Linux arm64 artifact cell keeps its hosted".

Compatibility note: the protected toolchain image's base and glibc version are
not stated in the sources read; the previous Ubuntu 22.04 floor is glibc 2.35.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
(cherry picked from commit 2f50233)

…and pin its guards

The prebuilt secret scan ran after comment lines were dropped, so a commented
`${{ secrets.NAME }}` inside a run block passed while GitHub still expands the
expression into the step script before the shell discards the comment. The
credential check and the runner policy now also read the raw job text for
`${{ ... }}` expressions. New rows put commented secret expressions (dotted,
indexed, dynamic index, toJSON and a format string containing a closing brace
pair) into the real prebuilt job and expect the finding, keep plain comment
prose and the GITHUB_TOKEN reference clean, change the job permissions in two
more ways than an added id-token, and give the Build step an `if:`, a
continue-on-error and a duplicate step name.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
(cherry picked from commit 8a23864)

…is a gkp job

release.yml prebuilt runs its linux-aarch64 row on the protected scalar
gkp-8cpu-16gb-arm64, so the runner-allowlist stage requires the file's line
in .github/runner-group-allowlist.txt. The line mirrors the live gke-protected
runner group entry (pineforge-engine release.yml at refs/heads/main).

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
(cherry picked from commit eda4a0d)

The mirror now lists release.yml, because its linux-aarch64 row runs on the protected GKE
runner gkp-8cpu-16gb-arm64. test_real_tree_mirror_preserves_the_live_group_and_only_two_advisories
still pinned the old nine workflow names, so it failed on the real tree with one extra
element (release.yml@refs/heads/main). That one test is test_ci_preflight_slice_5 in the
ctest gate and shard 6 of the preflight unit tests, which is why preflight, release, debug,
sanitizers and kernel all went red on the same row.

Add release.yml to the expected names, in the mirror's sorted order. The advisories are
unchanged: release.yml has a gkp job, so it adds none.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>

Main now carries engine 1.9.0 (#637) and the gkp-8cpu-16gb-arm64 actionlint label (#638).
This branch moves the release ARM row to that protected runner and needs the label on
main first; both are there now. A merge commit keeps the pushed history intact; no rebase
and no force push.

No conflicts. The branch's own diff against main is the CI change set only; the gate is
re-run on this merged head.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>