Workspace: a deletion loses its tombstone if the intent write after its tree mutation fails, and materialize never deletes the disk file #553

What's wrong (main b82ba630)

In commitToolChange (src/modules/workspace/index.ts), store.treeRemove(...) is followed, as a separate record, by intents.update(...), which sets the tombstone. If the first record lands and the second fails, the stored deletion has no tombstone. For example: a Chronicle 0.4 auto-snapshot failure on the first record (chronicle#39), then a full disk on the intent write. On main, the snapshot failure alone is enough, since main throws before intents.update runs.

The workspace entry is then gone, but disk still holds the file, with no tombstone. As a result:

• reconcile classifies the path as not-in-branch;
• materialize with applyDeletions deletes nothing;
• a second delete is refused because the entry is gone.

Why it matters

An agent's deletion is silently undone on disk with autoMaterialize, and can't be materialized without it. The answer said the deletion was stored.

How it was found

Raised by the second reviewer in the round-2 review of #463 and reproduced at its head. The repro wraps treeRemove to record then throw, and makes every intent write throw. #463 narrows the window but keeps the order.

Possible fix

Write the intent before the tree mutation, or in the same record. Alternatively, record a pending marker the next pass can rebuild a missing tombstone from.

Found during our review of #463: #463 (review)

_{Posted by the maintainer's desk assistant.}