[v0.4.1] Rolled-back transaction must not leave an unreadable not-exists CAS conflict

[zcourts]

Problem

A transaction that fails after staging work and is rolled back can leave an object key in a ghost state: a subsequent not_exists/fresh-head CAS conflicts, while a linearized read reports that no object exists. New transaction IDs and idempotency keys do not clear the condition.

This violates the MVCC visibility/precondition contract: an absent key must either satisfy not_exists, or a conflicting committed/readable value must be returned.

Production evidence

Developer Defence single-node deployment observed this after a quorum publication failed and rollback was requested. Worka native HMO attempt 25 independently logged device-capability persistence failing first with ObjectVersionPreconditionFailed and immediately afterward with object does not exist for the corresponding inference-target object. The Worka evidence is not yet sufficient to prove identical internal residue, but it is consistent and makes this a cross-application release concern.

Required outcome

• Rollback removes or invalidates every predicate-visible reservation, staged head, tombstone, and materialisation artifact owned only by the aborted transaction.
• not_exists evaluates against committed linearized visibility, not abandoned transactional residue.
• Do not make clients use unconditional writes to hide a readable concurrent head.
• Recovery must be safe across process restart and Raft replay.

Acceptance criteria

• Reproduce: stage an object with not_exists, force transaction failure after staging, rollback, verify linearized read is absent, then commit a fresh not_exists write successfully.
• Repeat with new transaction/idempotency identifiers and after restart.
• A genuinely committed concurrent head still conflicts and is readable.
• No stale reservation/materialisation record remains after rollback.
• Add an integration test using single-node local durability and another using multi-node quorum.

[zcourts]

Implementation written, not yet built (2026-07-29):

• Rolling back an open transaction now clears every staged point, range/predicate, write, manifest, outbox event, materialisation job, and idempotency result before durably marking it rolled back.
• Definite pre-certification failures (including topology/durability rejection before a Raft proposal) are typed and return the durable draft from Committing to Open, making an explicit rollback safe.
• Indeterminate certification failures remain Committing; Anvil does not falsely report rollback when Raft may already have decided the transaction.
• Tests prove rollback leaves no recoverable bundle or prepared-bundle pin, a fresh transaction identity can start, and definite pre-certification failure can be rolled back.
• A consensus test proves Absent accepts an authoritative visible tombstone version while still fencing concurrent changes.

No unconditional write repair and no client-side suppression is introduced. Formatting/diff checks pass; restart, local, and quorum integration acceptance remain for the consolidated build/QA cycle.