fix(registry): an unrelated borrow can no longer strand another secret in the emergency wipe

[deadpoets]

Two defects found by stressing the race-built core suite at GOMAXPROCS=4 to
match CI's 4-CPU Windows runners. One is a real bug in a security property; the
other is a flaky test that was misreporting a working control.

1. WipeAllSecrets could strand a secret behind an unrelated borrow

wipeAllInPlace runs two passes: the first wipes every region whose lock is
free at that instant, the second blocks on what is left. The second pass was a
sequential loop over the deferred slice, and that slice is built from Go map
iteration — so its order is random.

tryWipeInPlace reports done=false for a lock held at the moment it looks,
including a momentary one. So a buffer that was merely mid-WithBytes
during the first pass landed in the deferred set beside a genuinely stuck one,
and whenever it sorted behind that one it kept its plaintext for as long as the
unrelated borrow ran.

That is exactly the hostage situation the two-pass split exists to prevent,
reintroduced by the second pass itself — which also made the guarantee stated in
the surrounding comment false:

every other secret in the process is already zeroed by the time the first pass
returns

Fix: each deferred region is waited on in its own goroutine, so a borrow
that never returns blocks only its own buffer and the ordering cannot matter.

The goroutine count is deliberately unbounded. It is one per region still locked
when the first pass ends — normally zero, and bounded by the number of live
registrations. A worker pool would reintroduce the bug the moment stuck borrows
outnumbered workers.

Reachability: any WipeAllSecrets call, including from
InstallTerminationWipe, whenever a second buffer was in use as the wipe began.
Present since the two-pass wipe landed, so it is latent in v0.3.0/v0.3.1.

The regression test is deterministic

waitForWritersWaiting (already in the suite) observes writersWaiting on a
specific bufferRWLock, and that distinguishes the two implementations exactly:

• the fixed wipe waits on every deferred region independently, so each has a
  writer queued on its own lock;
• a sequential second pass can only ever have one queued at a time.

Both buffers are borrowed before WipeAllSecrets is called, so both are
guaranteed into the deferred set — no sleep, no timing assumption. Asserting a
queued writer on both locks then fails against the unfixed code regardless
of which key map iteration put first.

Verified: 3/3 fail against the pre-fix registry.go with
timed out waiting for 1 queued writers (got 0) — landing on stuck.mu or
idle.mu depending on map order, but always on one of them — and 10/10 pass
with the fix, 2.1s total.

2. TestSealCipher_RealOverflowStillDetected was flaky, ~1/256

Unrelated to the above, and not a product defect.

The test planted its overflow by writing a literal 0x00 over the first canary
byte. The canary pattern is 16 bytes of crypto/rand generated once per
process, so when that byte is already 0x00 the write plants nothing, Destroy
correctly reports no violation, and the test fails claiming the cipher masked a
real overflow. Observed at 1 process in 250, which matches 1/256.

corruptCanary (probeWrite(addr, probeRead(addr)^0xFF)) exists for precisely
this and is used by the other overflow proofs; its own comment names the 1/256
no-op as the hazard. This call site just missed it.

The canary check was correct on every run, including the failing ones.

Verification

• Full core suite under -race: green.
• Fixed build stressed at GOMAXPROCS=4: 0 failures across 150 targeted
  processes and 60 full-suite processes, all at -test.count=5. The sibling
  test this started from previously failed 1 process in 40.

Still open, not addressed here

A fatal error: stack not a power of 2 on windows-latest under -race, seen
once in CI (run 31982627382) and not reproduced locally. Tracked separately and
deliberately not guessed at in this PR.

[deadpoets]

Landed on main via the integration train in #55, as three commits:

• a752f3a — fix(registry): wait on each deferred region independently
• c72ec73 — test(sealcipher): plant the overflow with corruptCanary
• c04e1a3 — test(registry): make the hostage regression deterministic

Plus 9e2bfbc, which adds the Unreleased changelog entry for the x/crypto bumps that rode the same train.

Rebased locally rather than squash-merged so each commit carries the maintainer's SSH signature (verified=true). Different SHAs, hence the manual close.