DistributedSemaphore wakeup depends on unreliable FileSystem.watch event tags

Problem

DistributedSemaphore's release-notification path branches on FileSystem.watch event tags, filtering to Update | Remove and ignoring Create:

packages/@overeng/utils/src/node/file-system-backing.ts:376-379

Genie target locks use this backing.

Watch event tags turn out not to be reliable. Probing Effect 3 directly: a file can be created, modified and deleted — with fs.exists confirming it is gone afterwards — while no Remove tag is ever emitted, reproducibly, even when the operation is re-driven. Event ordering, coalescing of rapid writes, and tag classification all vary run to run within a single major.

So any consumer that decides what happened from the tag is building on an unreliable signal.

Why this is not urgent

DistributedSemaphore always races the watch push stream against a 100ms polling acquire loop. A missed or misclassified tag therefore delays wakeup by at most one poll interval — it does not cause a correctness or liveness failure. This is a fragile optimisation, not a live defect.

That is also why it has never shown up: the polling fallback quietly absorbs it.

Why fix it anyway

The tag filter buys nothing that path filtering does not already buy, and it depends on a property the platform does not actually guarantee. Treating any event on a watched path as a wakeup is simpler, strictly more reliable, and removes a dependency on behaviour that varies between runs — and between Effect majors.

Other FileSystem.watch consumers already do this: genie watch mode and both notion-md watchers filter by path only and re-read. megarepo's StoreLock explicitly strips the notification path and polls. This site is the outlier.

Proposed change

Treat any event on a matching path as a wakeup; drop the Update | Remove tag filter.

Acceptance

• no watch consumer branches on event tag classification
• a test covers wakeup on a Create-tagged event
• the polling fallback remains as the correctness guarantee, not the primary path

Context

Found while characterising FileSystem.watch behaviour for the Effect 4 migration (#925). Independent of that migration — it is a pre-existing property of Effect 3.

Start at packages/@overeng/utils/src/node/file-system-backing.ts:376-379 and trace the DistributedSemaphore release-notification path. Add coverage for a Create-tagged event, then verify that matching-path events wake the semaphore while the 100ms polling fallback remains; the acceptance checklist defines done.