Rename-twin repos: 24 read-back mismatches are stale duplicates; key read-back by doc id

[theboycoder]

Run 31667891477 (the first fully-batched enrich: 144 GraphQL queries for 2,156 repos, 93% under the unbatched count) reported 24 field-level mismatches: lastEnrichedAt sent at run time, stored 2026-08-10T23:4x — all 24 share that stale stamp.

Diagnosis: renamed/transferred repos (e.g. hyperledger-solang/solang, TENK-DAO/smartdeploy, MavenArchive/stelien, stellar-scaffold/cli, SwiftExWallet/SwiftEx, Moon-Launch/flow, web3-antivirus/soroban-cli-gui, zkbricks/lib-sanctum, flarcos/swplug-plugin, yripper/stellar-tools, +14 in the run log). The pass finds row A by the old name, GitHub returns the new canonical nameWithOwner, the write updates row A (persists fine) — but a stale twin row B already carries the new name from an earlier pass, and the name-keyed read-back finds B. The write is good; the corpus holds ~24 rename-twin pairs. This is the transfer edition of #783.

Fixes:

1. Re-run the dedupe wave (chore(guard): drop creit knownFailing — 783 fixed, probe RECOVERED #789 mechanism: keeper = scanned > has-notes > newest, promote-only merge, orphan delete, read-back) over these pairs.
2. Structural: verifyWrites should re-read by document id — the writer knows the exact row it updated; name-keyed read-back inherently re-litigates identity and will keep finding twin-class artifacts. Confirm-missing (PR fix(enrich): confirm-missing read-back + per-chunk batch degradation #840) already killed the false-accusation half; id-keying kills the residual class.

Until then this exact 24-row red will repeat on every full pass — known cause, data safe.