Epoch fence covers only the four composite writes; nine other mutation paths remain unfenced

[Hazzng]

Follow-up to #131 / PR #191, which closes #170's reproduction. Filing so the remaining exposure is not mistaken for closed.

Summary

PR #191 adds sandboxes.version and gates the conditional bump inside the advisory-locked ctx CTE of the four composite writes (writeFileComposite, appendFile's composite, mkdirComposite, rmComposite). A zombie writer whose lease lapsed is now rejected on those paths — verified end-to-end: replica-steal.mjs flipped from LOST UPDATE ... #170 reproduced to the property holds, with the blobs table and both replicas checked.

These mutations do not go through the composite path, so they are neither fenced nor do they advance the epoch:

bulkIngest · mkdir -p · rm -r · cp · link · symlink · chmod · utimes · truncate

Why it matters

Two distinct consequences:

1. A zombie writer performing only these operations can still silently lose an update — the same class of bug as Cross-replica silent lost update inside the heartbeat detection window #170, reached by a different door.
2. They do not advance the epoch. A live writer using only these paths leaves the counter unmoved, so a genuinely stale writer is not fenced afterwards, because the epoch it pinned still matches. The fence's precision depends on every mutation bumping it.

The second is the subtler one: it means the fence can be silently weakened by ordinary traffic, not just bypassed.

Not verified

No reproduction was written for any of the nine paths. The gap is established by reading which functions route through the composite CTE, not by observing a lost update through one of them. Whether each is reachable in the zombie window is unestablished — some may be unreachable for reasons specific to their call path.

Related

Delete/recreate also resets the epoch to 0, which is the tombstone problem tracked as #136.

Provenance

Found by the #131 implementation while scoping which writes the CTE covers.