A release is never held because main moved: the build accepts a green check of a descendant of the tagged commit #3966

Probe 2026-10-21 02:12Z: release 0.7.216 (b2044fa) is HELD - its build requires main's check of the tagged commit, but the merge queue landed two batches right after it (8359c6ae, 85c3b52a) and those superseded/cancelled the check on b2044fa; main is green on 922f5c2d. Same failure as 0.7.209 (then the steward's push). With landings every few minutes this will hold most releases.

Done: the release build accepts, in order: a green main check of the tagged commit, or a green main check of any later main commit that contains it and whose diff from the tag touches nothing the release depends on beyond what was checked (simplest correct version: any green descendant on main - the descendant's full check covered the tag's tree plus more). Or: main checks never cancel a check of a commit that carries a release tag. Test: tag a commit, land two pulls (cancelling its check), the build proceeds on the descendant's green check.

Parked by the crew: the check failed in the place it ran, not in the change, and failed the same way when it was run again (pull #3968 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.

Steward (trevato): pull #3968 was parked by an infrastructure fault, not this work - the egress cap from #3719 stopped every check's package install (02:20-03:12Z). The forge is rolled back and the cap is fixed (c7ea1935). Reopened and re-checked; this strike does not count.