Two TOCTOU-shaped gaps left by the terminality fix, both cases where closing the obvious hole left the adjacent one open. TERM-1: standingRemoval read the removal's code and discarded its CID, and Restore's removal-delete carried no precondition — so if a moderator replaced an admission-revoked removal with their own between the read and the commit, the edit deleted whichever removal was current, wrote the acceptance and ran the outbound side effect. The reversal the terminality branch exists to prevent, reachable again through a smaller window. The inspected removal's CID is now threaded into ExpectPrevCID; a mismatch commits nothing (side effect included) and re-runs the decision against the moderator's record. The vanished-removal direction no longer records a terminal ledger row for a removal that no longer stands, and the edit stays recoverable by redrive. PIN-1: restorePin read outbound_objects.LastCID — the last version FEDERATED — which the terminality fix guarantees is stale exactly when it matters, because an edit against a standing removal writes nothing outbound. A restore then signed the community's name to the pre-removal version: the one version we know the moderators did NOT reinstate, and one that may no longer resolve in the author's PDS. The admissions ledger's last evaluated CID is now the primary source, with LastCID as the documented fallback for a post whose latest decision IS what it federated (the common case) and for a deployment with no ledger wired. Both bite-proven. Test-side, both found by running the tests rather than reading the reports: the race fixture had discriminated Restore from AcceptSubject by the ABSENCE of a precondition, so the fix it drove made its own hook unreachable; and the ingest harness never wired the ModerationLedger that main.go wires, leaving restorePin's primary source dead under test while the fallback quietly passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>