[CMGS]

One registry fault can destroy a hibernated replicated claim that nobody adopted or released. This is on main today.

settleIntent took any row this node owns for the row its archive wrote, and deleted it. For a replicated claim that row is the replica's. Two sequences follow:

• No crash. The Replace of an archive fails, or its reply is lost, so ArchivePending stays. The next archive pass, 5 s later, settles the intent and deletes the replica row. writeArchiveRow then does Replace at the held epoch, finds no row, and refusedReplace reads that as an adopter finishing: dropAdopted removes the claim and its VM. A PostgreSQL outage that starts during the upload is enough.
• One crash. A restart mid-archive deletes the row and keeps the journal's epoch. The first unfence reads "row absent, epoch confirmed" as an adopter finishing, and drops the claim.

Fix. The row stays. A row naming the replica is left alone, and one the archive moved goes back to the replica. The row is never absent while the claim is held, so absent keeps its one meaning, and the claim stays adoptable from its replica while the archive retries. Deleting the row and zeroing the epoch also fixed both sequences, but left a window of absent row that a crash or failed journal write could still misread; it closed 7 of the 12 failures below, this closes 10.

Hot path: none. This runs only when an archive intent settles.

Evidence:

A fault matrix ran 1358 combinations of 11 scenarios, each durable step, 5 fault kinds and 6 continuations (heal, lease lapse with adoption, wake, release, a failing boot write, a sweep then a crash):

	claim lost	new violations
before	12
after	2	0

The other invariants (two serving owners, a released claim adoptable or served, a live row naming a deleted checkpoint) had no failures before or after. Checkpoint residue went from 97 lines to 95. The matrix is a temporary harness, not in this PR, with an in-memory registry whose compare-and-set arms were read against the PostgreSQL ones.

The two that remain both need a disk that keeps failing claim writes across a crash, plus a failing boot write or an hourly sweep. Both are left as they are: the disk failure is already loud, and no mechanism is added for it.

Tests in this PR, each failing without the fix:

• TestReplicaArchiveRetriedAfterARegistryFaultKeepsTheClaim
• TestReplicaRestartMidArchiveKeepsTheClaim

go test -race ./pool, the new tests -race -count=20, go vet and asl on both GOOS and the e2e module's tests pass.

Not run: hardware on this PR alone. The full hardware round runs on the tree with every open PR merged, and the result lands here.

Stacked on #420.

Update

• Archive rollback keeps a replicated claim's row. A failed journal write during an archive deleted the row, and the first unfence after a restart then removed the claim, its VM and snapshot. The fault matrix's two archive-replicated claim-lost lines are gone. A hardware run on tmpfs did not reach the journal failure, so this rests on the regression test and the matrix.
• No adoption while fenced or within 8 s of a lift, so after a registry outage every healthy owner renews before a peer can take its rows. Two nodes, PostgreSQL stopped 30 s: with this branch nothing is adopted and every claim keeps its VM; on main both healthy claims were adopted within 0.5 s of PostgreSQL returning.
• Unfence takes its own rows in one statement and one journal write (TakeOwned). Two nodes, 1000 replicated claims, restart to lift:

PostgreSQL round trip	this branch	main
local	0.02-0.07 s	0.35-0.41 s
10 ms	0.07-0.12 s	10.8-10.9 s
20 ms	0.18 s	never lifts: the pass outlasts the lease window every time, and all replicated claims answer 503

Conflict to expect with #424 in adoptArchived: keep the held check first, then the fence.