fix: the stale-branch gate reddened against a clean repo (C-320 addendum)

[Polichinel]

Recovers work orphaned from #416, and fixes the defect that produced it.

The defect

TestF8StaleBranches read git branch -a, which folds in remote-tracking refs — a local cache that goes stale the moment anyone deletes a branch, and that only git fetch --prune refreshes.

So the gate failed against a repository that was genuinely clean.

Demonstrated rather than argued: fabricating only a refs/remotes/origin/release/v1.11.0 ref — no branch on the remote, none locally — was enough to fail it.

It had already cost something. delete_branch_on_merge had removed every merged branch from the remote; the gate went red anyway; nine local branches were deleted chasing a problem that did not exist.

This is C-320's own failure mode, inside C-320's own test file: a gate that reddens for reasons unrelated to what it asserts stops being read.

The fix

Split into two checks with two sources of truth:

Check	Source	Offline
local release/* leftovers	git branch	always works
remote release/* leftovers	git ls-remote — authoritative	skips, per this file's C-320 idiom

Drilled on this branch, not carried over from the earlier run

Clean repo	passes
Stale remote-tracking ref only	passes — the old false positive
Real local leftover	fails correctly

Also recovered here

Both were orphaned when I pushed to docs/postmortem-v190-v1110 after #416 had already auto-merged. No error was raised; the work simply was not on development.

• C-320 addendum recording the defect — registered there rather than as a new concern, since it is the same root cause with an existing home.
• The post-mortem's fourth guard-drill finding, since this was found while writing the document about exactly this failure mode.

Verification

Full suite exit 0 · ruff clean · validate_docs.sh exit 0 · register invariants unchanged (index 1764 < 8000, header ≤ 3500)