Windows->WSL (Plan 9) is ~26x native on metadata and ~73x on reads - consider a Windows-side metadata cache

**Scope — not a duplicate of #4197.** That issue and most filesystem-performance threads concern `/mnt/*` (Windows files seen from Linux), which is being worked on. This is the opposite direction: Linux files seen *from Windows* via `\\wsl.localhost` / `\\wsl$`, which Windows-side tooling — editors, `git.exe`, indexers, build systems — uses constantly.

### Problem

Same machine, same 3,000-file tree, warm:

| | walk (enumerate) | read (all bytes) |
|---|---|---|
| native, inside WSL | 4 ms | 39 ms |
| `\\wsl.localhost` (Plan 9) | 104 ms | 2856 ms |

The ratios are the interesting part: reads are ~73× native, but the *walk* is ~26× native while transferring almost no data. The cost tracks the **number of filesystem operations**, not bytes — every `stat`, `readdir` and negative lookup is a round trip across the VM boundary. Windows tools are unusually round-trip heavy (a Windows `git status` on a WSL repo issues tens of thousands of them), which is why this direction feels worse than raw bandwidth numbers suggest.

### Proposed solution

Cache directory metadata on the Windows side of the Plan 9 client, kept coherent by a change-notification channel from the Linux side, so `stat` / `readdir` / negative lookups are served locally instead of round-tripping. Most of the gap appears to be recoverable this way without touching bulk read/write throughput.

### Alternatives considered

- **Per-tool workarounds** — routing commands through `wsl.exe` (e.g. desktop/desktop#22044). Works, but every tool needs its own fix, and it does nothing for Explorer or an editor's file watcher.
- **Keeping the working copy on NTFS** — gives up ext4 performance for the Linux-side workload, which is usually the reason for using WSL2 in the first place.
- **Testing the premise out-of-tree.** I implemented the caching approach as a WinFsp filesystem to check whether it actually pays off: https://github.com/zcsizmadia/wsldrive (MIT). The numbers above come from its benchmark harness; with the metadata mirror in place the same walk is 39 ms. **I am not proposing that you adopt it** — only offering it as evidence that client-side metadata caching recovers most of the per-operation cost, and that the idea may be worth considering in the platform, where it would benefit every tool rather than one at a time.

### Additional context

- Windows 11 10.0.26200, WSL 2.7.8.0, kernel 6.18.33.1-1, Ubuntu (WSL2)
- The win is per-operation, not per-byte: a single large sequential copy is roughly a wash, so this is not a claim about bulk throughput.
- Happy to share the benchmark harness or a more detailed profile if that would be useful.

Start by reviewing the Windows-side Plan 9 client and the linked wsldrive benchmark harness, focusing on metadata operations such as stat, readdir, and negative lookups. A complete proposal would define a coherent metadata cache and Linux-side change-notification channel, then demonstrate improved walk performance while preserving correctness.

Written by the indexing model from the issue text.