ci(release): complete the candidate-aware promotion pipeline on release-1.6 - #3893

Workflows run from the ref they fire on, so a tag pushed on this branch
executes THIS tags.yaml, not main's. main grew an rc-e2e job on
2026-07-24; release-1.6 never did. The v1.6.1-rc.1 push therefore
produced only Prepare Release, a skipped changelog and skipped website
docs — no E2E Release Candidate job at all. Promote RC looks for its
evidence by exact job name, found none, and v1.6.1 was promoted with the
gate bypassed. That is the hole this closes.

Add e2e-tag.yaml byte-identical to main and call it from a new rc-e2e
job. The suite step works as written here because this branch already
carries hack/e2e-chainsaw/ and a test-chainsaw target, and the sandbox
image already installs chainsaw 0.2.15.

Two things make the wiring load-bearing rather than cosmetic:

  * the called job's name must stay "E2E ${{ inputs.tag }} (full suite)".
    Promote RC composes the string it searches for from the rc tag, and
    GitHub renders a called job as "<caller> / <called>", which the
    gate's suffix matcher accepts. Rename either side and the gate fails
    closed.

  * the caller must grant contents: read AND checks: write. A caller's
    permissions are the ceiling for every job in the called workflow and
    GitHub validates that ceiling statically, at run creation, before any
    `if:` is evaluated. e2e-tag.yaml's e2e job declares checks: write for
    a dispatch-only breakpoint workflow_call can never reach, so omitting
    the grant would fail the entire tags.yaml run for EVERY tag push, rc
    and stable alike, building nothing.

prepare-release already publishes the rc as a non-draft prerelease with
the nocloud-amd64.raw.xz asset and pushes the release-X.Y.Z-rc.N staging
branch before rc-e2e can start, which is exactly what e2e-tag.yaml's
resolve job requires.

Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>

Since the promote PR is based on release-1.6, the changelog it carries
merges onto the maintenance line and never reaches main. The backstop job
in tags.yaml only asks whether the file is on origin/main, so it sees
"absent", spends an AI run, and produces text nobody reviewed — which
update-releasenotes.yaml then pushes into the published release body,
overwriting the reviewed notes the release actually shipped with.

Ask the second question too. `at_tag` is whether the changelog is present
in this checkout, which is the tag commit and therefore the promote merge
commit. When it is, port that reviewed file to main verbatim and skip
generation entirely; the AI now runs only when the changelog is genuinely
absent on both sides.

Add hack/validate-changelog.sh, byte-identical to main, and gate the
commit on it. A ported file came from the tag and a generated one came
from a step that is deliberately allowed to fail, so neither had been
checked: the old guard only asked whether the file was non-empty, which a
truncated Copilot stream satisfies. The validator asserts the H1, the
release-link comment, the trailing compare link and at least one section,
all carrying the expected version, so a fragment or a changelog generated
against the wrong tag cannot reach a release body.

Verified against this branch's own shipped changelogs: v1.6.1, v1.5.2 and
v1.5.1 all pass, and v1.6.1 checked against 1.6.2 fails as it should.

This takes effect for tags cut after it lands — tags.yaml and the script
it calls both come from the tag's own tree.

Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>

hack/verify-promoted-packages_test.bats is byte-identical to main: 13
tests driving the verifier against a mocked `flux`, so they need no
registry. They cover the fail-open shapes that matter most — an
unreadable file during the rc-reference scan, a collector that returns
nothing, a digest that moved while candidate and merge tree still match.

hack/promote-gate-contract.bats is NOT main's copy, and the difference is
deliberate. main's version pins a `parse` job, a `skip_e2e_gate` input,
promote-time changelog and website-docs jobs, and the `labeled`
pull_request trigger they depend on — none of which exist here, because
`Promote RC` is a workflow_dispatch and runs from the ref it is
dispatched from, which is main. Run verbatim against this branch it fails
on its first test and the runner aborts the suite.

So this pins the half release-1.6 actually owns — the producer side:

  * an rc tag push calls e2e-tag.yaml with the pushed ref, only for
    -rc. tags, and grants the static permission ceiling the called
    workflow declares;
  * the called job's name is the exact literal main's gate composes and
    searches for, asserted with grep -F because `${{` as a basic regular
    expression matches nothing and would make the pin pass by finding its
    own subject absent;
  * the suite it runs is the full one (empty CHAINSAW_SUITES), with the
    Makefile target and the sandbox chainsaw binary it needs;
  * all five files promote-rc.yaml's preflight reads off the target base
    are present, plus the two libraries the verifier sources by relative
    path;
  * verify-release-candidate is keyed on author and head branch and
    carries NO label condition, so restoring main's from muscle memory
    switches the job off here and fails this test instead;
  * the candidate verification precedes the stable tag, the submodule
    tag, the release publish, the retag and the chart publish, and
    follows the toolchain, the login and the tooling checkout it needs;
  * the tag-time changelog is validated and ported, not regenerated.

Every pin was mutation-checked: breaking the thing it describes turns it
red.

Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>