corpus: re-record the four drifted entries against reconverge 0.3.0

[vyncint]

Today — four of the nine corpus entries have drifted, and the scan has been reporting it since 0.1.12: issues #7 (0.1.12), #8 (0.2.0) and #9 (0.3.0). Those are one behaviour change reported three times, not three findings — the drift set is identical in all three, so whatever moved, moved by 0.1.12 and has been stable across two releases since.

Read against the oracles, measured 0.1.6 → 0.3.0:

entry	oracle	recorded	now
ci-gate-lost-to-a-barrier-above	KNOWN_UNSAFE	rc001/warning,rc001/warning|0w	rc001/confirmed,rc001/warning|1w
guard-inside-loop-not-promoted	KNOWN_UNSAFE	rc001/warning|0w	rc001/confirmed|1w
lane-env-barrier-below-is-harmless	KNOWN_UNSAFE	rc001/confirmed,rc001/warning|1w	rc001/confirmed,rc001/confirmed|2w
witness-reaches-only-a-prefix	KNOWN_UNSAFE	rc001/confirmed,rc001/warning,rc001/warning|1w	rc001/confirmed,rc001/confirmed,rc001/warning|2w

Every entry that moved is KNOWN_UNSAFE and moved warning → confirmed with more witnesses — the analyzer proving what it previously only suspected. The two entries where movement would have been a false positive did not move: unreachable-barrier-still-reported (KNOWN_SAFE) and correct-partial-warp-mask-not-gated (KNOWN_MASK_VALID) are both unchanged.

So this is an improvement, and a substantial one. Two of the four entries are notes about limitations reconverge has since fixed — ci-gate-lost-to-a-barrier-above's note says in as many words "If this becomes confirmed, reconverge fixed it", and it has.

Why it is worth fixing — a corpus recorded against 0.1.6 is not watching for anything. The hourly scan re-reports a known four-year-old result while a new regression in the same entry would be invisible: the signature is already "wrong", so moving from one wrong value to another changes nothing about the report. The corpus stops being a regression corpus the moment its expectations are stale, and it has been stale for three releases.

There is a second cost. Two of these entries document limitations that reconverge's own Limitations section may still claim — guard-inside-loop-not-promoted's note says "reconverge's Limitations section does not mention loops". If loops are now handled, that is a documentation fix upstream that nobody knows to make.

Fix — re-record the four entries against 0.3.0: regenerate each case, re-run corpus add, and update analyzer_version, measured_on, expected_signature and the note. The notes are the part that matters; a re-record that only moves the signature loses the finding. Each note should say what the entry was evidence of, that reconverge closed it, and in which version.

Two entries need more than a re-record:

• guard-inside-loop-not-promoted is now misnamed — the guard is promoted. Either rename it or restate what it pins.
• lane-env-barrier-below-is-harmless is filed separately, because its finding is no longer observable through its signature at all.

Needs the pinned nightly with rustc-dev, llvm-tools and rust-src, as .github/actions/analyzer sets up.

Done when — just regress is clean against reconverge 0.3.0; each re-recorded entry names the version that closed it; #7, #8 and #9 are closed with a pointer here; and anything reconverge's own docs still claim as a limitation is filed upstream.