auto-publish FS.GG.Kit with a bot-authored evidence PR, replacing the manual per-version release cycle #2106

Every edit to a declared kit source forces an FS.GG.Kit version bump (kit-published-coherence's
pr-arm), and main then carries a red published arm until someone tags and publishes. The
release itself is already fully mechanized; what is manual is the choreography around it. At the
current cadence — 0.24 → 0.27 in a few days, with 0.27.1 already owed behind two in-flight PRs —
that choreography is re-derived by hand every time.

Decision, already made

The maintainer has decided: auto-publish, with a bot-authored evidence PR. This item builds that.
Do not re-litigate the choice; the alternatives (hold-for-approval, or a fresh per-version backlog
row each time) were considered and rejected.

What is already mechanized, and must not be loosened

release-kit.yml fires on any tag push and already runs the entire safety posture: locked restore,
src/FS.GG.Kit/verify-package.sh (repos.lock parity, pack/content assert, materialize into a fresh
receiver root including skill-view roots/views/adopt semantics, tamper-loud check), dotnet pack,
a consumer-restore smoke test, then push to GitHub Packages followed by nuget.org via OIDC Trusted
Publishing, then receiver notification via scripts/dashboard-tick.py.

The dual-feed byte-identity is a structural property of that pipeline — it packs once and pushes
the same artifact twice, never re-packing. The manual SHA-256 comparison performed during #2093
was an audit of that guarantee, not the guarantee itself. Preserve the structure; do not replace it
with a post-hoc comparison and call that equivalent.

What is manual today

1. Noticing the red published arm — already redundant with the gate's own scheduled/push detection.
2. Deciding to tag — a judgement call, but one the maintainer has articulated as standing policy:
   the version is authored in the PR and the release cuts afterward. That is the designed flow, so
   the release is owed rather than optional.
3. Hand-writing the changelog evidence prose.
4. A full pnext-item dispatch-and-review cycle for a two-line evidence PR whose real subject is
   verifying claims that are already true by construction.

The tradeoff this accepts, stated plainly

This removes the confirm-before-every-irreversible-publish checkpoint. #2093 treated that
checkpoint as load-bearing and it worked: the worker stopped, the premises were re-verified, and the
publish proceeded on an explicit go-ahead. Automating it means pre-approving any version bump that
has already passed pr-arm as auto-publishable.

The maintainer has accepted that tradeoff. Because a published package version cannot be cleanly
unpublished, the bounds of that pre-approval must be written into the mechanism rather than left
implicit — see acceptance criteria.

Acceptance criteria

• A scheduled/push check against main detects an authored-but-unpublished FS.GG.Kit version and
  auto-tags, triggering release-kit.yml with every existing gate unchanged. If any gate is red,
  it must not publish and must escalate visibly — reuse .github#2095's escalation shape (blocked
  label plus one sticky marker-addressed comment carrying a streak count), not an hourly error
  addressed to nobody.
• The workflow opens the registry/CHANGELOG.md evidence entry as a bot-authored PR at publish
  time, mirroring the skill-registry-autofix bot pattern, carrying the real evidence: the
  release-kit.yml run id, both feed URLs, the resolved version, and the repository commit both
  nuspecs record. Human/critic sign-off happens on that PR; a full dispatched-worker cycle is not
  required.
• Write the bounds of the pre-approval into the mechanism. State explicitly what it will publish
  without asking (a bump that passed pr-arm on a merged PR) and what it must refuse and escalate
  instead. At minimum it must refuse: a MAJOR bump, a version that already exists on either feed, a
  bump not reachable from a merged PR, and any run where the feeds disagree. These are the cases where
  "cannot be unpublished" actually bites.
• Handle the partial-publish case deliberately. If the pipeline pushes to one feed and fails before
  the other, it must escalate loudly and must not retry blindly — a half-published version is a state
  a human should adjudicate. #2093's worker was explicitly instructed to stop and report on this
  case; encode that instruction rather than losing it.
• The increment semantics must be decided by rule, not per-worker guess. Two PRs in one unpublished
  window independently characterised the same bump as PATCH (.github#1933, prose-only) and argued
  MINOR (.github#2080, receiver-visible). Both converged on 0.27.1 for collision avoidance, which
  settles which number but not what it means. State the rule the gate enforces.
• The mechanism must be idempotent and must not race itself: two triggers in the same window must not
  produce two tags or two evidence PRs.

Verification

• Demonstrate against a real bump — 0.27.1 is owed right now and is the natural fixture, exactly as
  PR registry: re-digest stale skill rows (auto) #2078 was for .github#2095. Do not verify against a hypothetical.
• Show the refusal paths firing: a version already on a feed, and a red gate.
• Show the evidence PR opening with correct, checkable content, and confirm the published artifact is
  byte-identical across feeds by the structural route rather than a bolted-on comparison.

Note on sequencing

FS.GG.Kit 0.27.1 is owed as soon as .github#1933 (PR #2100) or .github#2080 (PR #2101) lands.
Until this mechanism exists, that release is manual. Whoever takes this should decide whether to
publish 0.27.1 by hand first and then build, or build and let the mechanism cut it — and say which.

Paths: .github/workflows scripts registry/CHANGELOG.md docs/adr .github/workflows/** scripts/** docs/adr/** work/2106-auto-publish/** readiness/2106-auto-publish/** tests/kit-auto-publish/**

Class: hardening