deps: libuv: cherry-pick fsevents path cleanup - #67293

…ced (#906) (#921)

Closes #906.

## Cause

On macOS, libuv uses one FSEvents stream for all directory watches.
Every `fs.watch` open or close rebuilds that stream and leaks memory for
every watched folder (libuv/libuv#5283, not in a Node release yet;
nodejs/node#67293). `oxnode watch` reopened a folder's watch whenever
the folder got a new inode, so replacing folders made memory grow
without limit.

## Fix (macOS only)

FSEvents watches the path, not the inode, so a folder's watch now
follows its path:

```
folder replaced, same real path   → look at its files again, no reopen
folder missing                    → check its files once, keep the watch for `linger` (60 s)
watch no longer needed            → keep it for `linger`, then close
new real path (link moved)        → reopen
```

Linux and Windows behave as before (`linger` is 0 there, and a new inode
still means a new watch).

## Results

The issue's repro: 400 folders, each replaced with
`mv`/`mkdir`/`mv`/`rmdir` every round, measured with `vmmap`.

| | footprint | watches opened |
|---|---|---|
| main, Node 26, 5 rounds | 25 → 131 MB, still growing | 401 → 2915 |
| this PR, Node 26, 10 rounds | about 36–40 MB, flat | 401 → 402 |

Node 22 and 24 give the same shape: on main memory grows to 117–143 MB,
with this PR it stays flat.

## Tests

New macOS cases in `watch-units.spec.ts` use a fake `fs.watch`, so they
run on every OS:
- a folder replaced by `rm -rf` + `mkdir` or by a rename keeps its watch
- a missing folder: its files are reported gone, its watch closes after
`linger`, and the parent's watch closes once the folder is back
- a parent renamed away, and a walked folder removed with its
subfolders: the files in them are reported gone
- a watch reached through a link that is repointed, or a folder moved
away and then linked back: the watch is reopened
- a watch no longer needed lingers, serves again, then closes

There is also one test on real FSEvents (macOS only): 40 folders
replaced 3 times open no new watch.

## Known trade-off

A folder deleted for good keeps its watch for 60 s, where before it
closed at the next sync. This only adds cost when a tool keeps creating
and deleting new folders inside an `--include` root. The extra watches
are about rate × 60 s, and their number stops growing.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>