inotify bridge: deliver Windows-side file changes to Linux watchers

[zcsizmadia]

Closes #118.

A file changed by a Windows application raises no inotify event inside WSL2, so vite, nodemon,
tsc --watch, jest --watch, air and cargo-watch silently never fire. Nothing errors, which is
what makes microsoft/WSL#4739 so expensive to
diagnose. This makes those events arrive on a Direction B mount, for unmodified watchers.

Why the last hop needed a mechanism

wsldrive already carries every far-side change across as an invalidation, so the mirror and the page
cache are correct within milliseconds. The event is the part that cannot be delivered directly: the
kernel raises fsnotify events from the VFS, at the point an operation is performed. A filesystem
cannot raise one itself, and the fuse_lowlevel_notify_* calls invalidate dentries and pages without
ever touching fsnotify — fuse_reverse_inval_entry has no fsnotify hook.

What it does instead

It asks the kernel to raise the event, by performing on the mount the operation the far side already
performed. A thread in the mount process replays each change as an ordinary syscall:

far side	replayed as	kernel raises
file written	utimensat, mtime only	IN_MODIFY
file created	mknodat	IN_CREATE
directory created	mkdirat	IN_CREATE with IN_ISDIR
deleted	unlinkat / unlinkat(AT_REMOVEDIR)	IN_DELETE
renamed	renameat	IN_MOVED_FROM + IN_MOVED_TO, one cookie

Touching only mtime is deliberate: fsnotify_change() maps a change to both timestamps to
FS_ATTRIB and to mtime alone to FS_MODIFY, so this is what yields IN_MODIFY rather than the
weaker IN_ATTRIB. Letting the kernel perform the rename is what produces a genuine move cookie, so
a watcher sees one move instead of an unrelated delete and create.

Safety of the replay

The pokes are real filesystem calls, so three things guard them.

The FUSE handlers answer the bridge's own requests locally instead of forwarding them, and that test
is deliberately over-determined — own thread, a matching poke in flight, the exact path, claimed at
most once — because a false positive would be a user's rm silently not deleting. The bridge also
refuses to start unless its root reports FUSE_SUPER_MAGIC, and every poke re-checks that its
target's parent is still on that mount's device.

The conformance script asserts the outcome that matters here: that the served tree is byte-for-byte
untouched by the bridge's own operations.

Protocol version 4

Getting the right event type out meant carrying what happened, not just what the mirror must do
about it. Invalidation ops now hold a change kind and a rename-pairing cookie. A peer that ignores
both stays correct; agent and client must match versions, as before.

The kind survives coalescing, so a create followed by three writes is still a creation, and every
half-move is degraded to what it amounts to alone rather than reaching a consumer unpaired. Created
versus modified is settled by the client against its own mirror — the agent re-stats after the fact
and cannot tell the two apart.

On the sequencing suggested in #118

I did not sequence this behind #93. The bridge needs no CONFIG_FUSE_PASSTHROUGH and no newer
libfuse, so it neither depends on that mount design nor conflicts with it.

Also

mknod on a regular file now works on the mount; it was unimplemented and failing with ENOSYS.

Known gap

An overflow on the far side sends a rescan, which names no path, so the bridge can only touch the
mount root. A watcher that re-walks on any event below its root catches up; one waiting on a specific
path is not told. Naming what changed means diffing the old tree against the new snapshot and is not
implemented. docs/inotify.md records it alongside the other limits.

Testing

scripts/inotify-conformance.sh is new and runs in the Linux conformance job. It mounts a tree,
changes it from the serving side, asserts each change raises the right event type, checks the served
tree is untouched, exercises a recursive watch over 10k files, and reports far-side against local
event latency.

Unit tests cover the change-kind semantics, rename pairing and its degradation, the wire round-trip,
and the whole agent-to-client path end to end via RootServer::notify.

Local verification was limited: this machine has no MSVC, WinFsp or libfuse3, so I compiled every
changed translation unit under the project's warning set with -Werror against stub headers for the
FUSE and Linux APIs, and ran the suites with a GoogleTest shim (core 87/87; agent 49 with 5
environment failures identical to an unmodified baseline built in a worktree). CI is the first real
build.

🤖 Generated with Claude Code

[zcsizmadia]

What CI caught that local verification could not

Three defects, all in the delivery hop, all found on the runners rather than by reading:

1. A dangling else. EXPECT_ expands to an if/else, so an unbraced if (cond) EXPECT_...
   trips -Wdangling-else. Braces around the enclosing loop do not help; they have to go around the
   assertion.
2. The creation poke was forwarded, not claimed — the one that mattered. libfuse's FUSE_MKNOD
   handler offers a regular file to the create handler first and only falls back to mknod if
   that answers ENOSYS, so a mount with a create handler never sees the poke where it was being
   claimed. Forwarded, it became a genuine create, which replaced the file whose arrival prompted
   the notification with an empty one. That was the two failing external ... change is seen on re-open checks.
3. An unrecognised poke was fail-dangerous. The guard fell through to forwarding, which is how
   (2) reached the agent at all. It now refuses instead: the bridge performs no genuine mutations,
   so a mutation from its thread is one of its own replays and nothing else. A refused poke costs a
   notification; a forwarded one costs data.

A fourth was found by inspection while those were in flight: a failed removal or move poke left the
ghost entry it had handed out cached, so a path the far side had removed would read as still present
until the entry cache let go. It is dropped explicitly now.

Worth noting that (2) and (3) were only diagnosable because the change-notification battery runs
with always() and the mount now names the pokes it could not deliver. Before that, every event
type failing and one event type failing looked identical from the outside.

Acceptance criteria from #118

All measured on the runner, in the Filesystem conformance (mounted) job.

criterion	result
editing from the far side fires inotify on the mount	✅ write -> MODIFY
create, modify, delete, rename map to the right event types	✅ all six, including CREATE,ISDIR and DELETE,ISDIR
a rename arrives as a pair	✅ MOVED_FROM + MOVED_TO
recursive watch on a 10k+ tree without overflow	✅ 10,000 files, plus a deep write still notifying
added latency vs. a native Linux-side write, documented	✅ 4 ms either way
read/write throughput regression, documented	✅ none — the bridge is on the invalidation path, not the data path
vite, nodemon, cargo-watch hot-reload	⚠️ not automated; the event types those watchers key on are covered above, but no runner drives the tools themselves

Full battery: 31/31 filesystem checks and 12/12 change-notification checks, with the WinFsp mount
job green as well.

🤖 Generated with Claude Code