chore: the trunk declares its lane too

[captainpacket]

Forward-ports the release-lane change from maint/2.9.x (#360) so both branches carry the same tooling. Without it the two lanes diverge in the release path itself — the part hardest to reason about and most expensive to get wrong — and a future 3.x maintenance branch would have to rediscover the whole change.

main's release behaviour does not change. Its lane names main, so every gate resolves to exactly the ref it resolved to before. This is a refactor with one new refusal, not a change to how a release works.

The trunk declares no series

LANE = ReleaseLane(branch="main", ruleset="main-release-integrity")

A maintenance lane exists to carry exactly one series; the trunk is where the next one is born. Pinning it would refuse 3.1.0 the day it is cut, and the failure would look like a bug in the guard rather than a stale declaration. series=None is the absence of a check that never applied here — ancestry stays the real gate.

The stale prior-release tag was worse on this branch

release.yml fetched refs/tags/v2.9.1 as a literal so the bridge check had an object to resolve, and nothing advanced it when the anchor moved. On the maintenance branch that was one release stale; here it was two — this branch has released 2.9.2 and 3.0.0 since, and PRIOR_RELEASE_TAG says v3.0.0. The next 3.0.x release would have failed fetching a tag it no longer needs while missing the one it does. Both the lane and the prior tag now come from the scripts.

How each file was ported

• verify_release_provenance.py taken wholesale from the maintenance branch with this lane's two anchor constants restored. The files differed by nothing else, so copying is provably equivalent to re-applying and cannot drift.
• release.py re-applied, because it differs by ~300 lines of stage-idempotency work (fix: ask two liveness questions about a release pull request, not one #358/fix: a release stage can be run twice #359) that exists only here — including four origin/main sites the maintenance branch does not have (_merge_is_live, _head_is_merged, _text_on_main).

One literal legitimately differs between lanes

The provenance fixtures release 3.0.1 here and 2.9.3 on maint/2.9.x. That is required rather than incidental: the maintenance lane's series guard would refuse a 3.0.1 fixture, which is the guard working. Every other difference between the two copies is a declared lane value.

Verification

• python -m pytest scripts/tests — 409 passed.
• Live: python scripts/verify_release_provenance.py --controls-only against the real main-release-integrity ruleset — the check that refuses a release from an unprotected branch.
• pre-commit run --all-files clean; check_harness.py --base origin/main passes.
• The lane values are asserted directly: this branch's lane must name main and declare no series, so a merge carrying the maintenance lane's declaration here fails a test rather than a release.

No shipped code changes — packages = [{include = "forward_netbox"}].

Merge #360 first, so the maintenance lane is not left behind a trunk that already knows about lanes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DczGsTTkuwULnpcYX4qui6