feat: gate stable promotion on security qualification instead of pre-release publication

User Story

As a maintainer running the weekly release train, I want security scan findings
to gate promotion to stable rather than building and publishing a
pre-release, so that a static-analysis backlog cannot stop the release
pipeline from producing artifacts to qualify.

Problem Statement

release-tag.yml calls the aggregate Security Scan as a precondition for
publication. Any blocking finding from Codex Security, CodeQL, Trivy, Zizmor, or
Cargo Deny fails the workflow before artifacts are published.

RFC 0014 specifies the opposite ordering. In
rfc/0014-release-stability/README.md (Pre-release qualification and stable
publication), every pre-release is tagged and built first, and the four
qualification suites — including Security review, which "verifies security
scan results, reviews changes to security-sensitive boundaries, and confirms
that every finding has the required disposition" — run against the published
artifacts. Qualification determines eligibility for stable promotion; it is not
a precondition for the pre-release existing.

The current wiring conflates the two. A finding backlog unrelated to the
candidate commit stops artifact production entirely.

Impact / Why This Matters

Observed on release-tag run 35725722342 (2026-09-22): the nightly failed with
8 HIGH/CRITICAL CodeQL findings, 27 HIGH Zizmor findings, 1 HIGH Trivy finding,
and one Cargo Deny advisory (RUSTSEC-2026-0295). No pre-release artifacts were
produced, so nothing was available to qualify, and the release train stalled.

The current workaround is the temporary fail-on-static-findings: false
override added in #3552, which makes CodeQL, Trivy, and Zizmor informational on
the release path. That unblocks the train but removes the signal entirely rather
than relocating it — there is no gate anywhere that stops a stable promotion on
those findings, and the override is documented only in prose in CI.md and
architecture/build.md.

The workaround is insufficient because it trades a false blocker for no blocker.
RFC 0014's model keeps the signal and puts it where it belongs.

Proposed Design

User-facing workflow

1. A pre-release tag always builds and publishes its artifacts. Scanner
   execution errors still fail the build, because a scan that did not run
   produces no evidence.
2. Security scans run as a qualification suite against the published
   pre-release, alongside conformance, upgrade, and breaking-API review.
3. The suite's result — per-scanner counts and the disposition of each finding —
   is recorded in the pre-release manifest described in RFC 0014.
4. Stable promotion requires the security suite to pass. A pre-release with
   undisposed blocking findings is ineligible for promotion and is reported as
   such, rather than silently skipped.
5. Maintainers dispose of findings (fix, accept with justification, or mark
   false positive) against a pre-release, and that disposition is what the
   promotion gate reads.

Externally observable behavior

• A finding backlog delays stable promotion; it never prevents a pre-release
  from being built or published.
• The reason a pre-release was not promoted is visible in its manifest and
  qualification result, not only in a failed workflow log.
• fail-on-codex-findings and fail-on-static-findings on security-scan.yml
  are no longer needed on the release path once the qualification gate exists,
  and the temporary override in release-tag.yml is removed.

Internal implementation — where the suite runs, how dispositions are stored, and
the manifest schema — is deliberately left open.

Acceptance Criteria

• Pre-release tags build and publish artifacts regardless of scanner
  findings; only scanner execution failures block the build.
• Security scan results are attached to the pre-release manifest with
  per-scanner finding counts.
• Stable promotion is blocked when the security qualification suite has
  undisposed blocking findings, and the block is reported with the specific
  findings responsible.
• The temporary fail-on-static-findings: false override is removed from
  release-tag.yml.
• CI.md, architecture/build.md, and the RFC 0014 release qualification
  supplement describe the enforcement point consistently.
• A pre-release with a known backlog is demonstrated publishing successfully
  and being correctly withheld from stable promotion.

Alternatives Considered

• Baseline/delta enforcement inside release-tag.yml. Keep publication
  gated, but only fail on findings new since the previous stable tag. This is
  the removal condition currently documented for the #3552 override. It fixes
  the immediate backlog problem but keeps enforcement in the publication path,
  so it still contradicts RFC 0014 and still lets a single new finding block
  artifact production.
• Keep blocking and burn down the backlog. Triage the 8 CodeQL, 27 Zizmor,
  and 1 Trivy findings to zero, then restore fail-on-static-findings: true.
  This does not change the structural problem: the next backlog stalls the train
  again, and it couples release cadence to triage capacity.
• Leave the override in place indefinitely. Rejected — it removes the signal
  with no compensating gate before stable promotion.

Agent Investigation

Related material:

• RFC 0014 — rfc/0014-release-stability/README.md,
  rfc/0014-release-stability/release-qualification.md
• #3552 — introduced the temporary observation mode this issue supersedes