zit 0.3.32

zit 0.3.32 makes zit purge undo take the repository's write lock before it restores anything, like every other command that writes the store.

No artifact, tag namespace, sync message, or on-disk repository format changed.

purge undo waits its turn

A zit repository is one append-only file, and every writer takes an exclusive lock on it before appending: commit, clone, pull, a server receiving a push, config and user-table writes, tags, tickets, wiki and forum posts. Two writers that are not serialised both scan the file for its end and both append there, so the second writes on top of the first. The overwriting frames are complete and checksum-valid, so neither zit verify nor crash recovery can see that anything happened: one of the two writes is simply gone.

zit purge undo restores buried artifacts by appending them, but it opened the store without that lock. Run while a commit, a pull loop or a server push was writing to the same repository, from this checkout or another worktree of the same store, either the restored artifacts or the other writer's check-in could be lost without a trace.

It now opens the store the way every other writer does, so it waits for a concurrent writer to finish rather than racing it. The same change makes it resolve a detached worktree's store, which the old direct open did not.

The regression test holds the repository's write lock, starts zit purge undo, and checks that the store is byte-for-byte unchanged a second and a half later. It then releases the lock and checks that the undo completes and the restored store verifies. Against the old code, the store changes while the lock is held and the test fails.

Compatibility

• No on-disk repository or wire format changed; Fossil RFC revision 00 remains the target.
• zit purge undo now waits, without a message, while another zit process is writing to the same repository.

Qualification

zig fmt --check, zig build test, e2e, smoke, git-import-e2e, git-export-e2e, and dst, plus the three-runner CI battery.