fs: report errors from recursive watch events

[codeNinja62]

Fixes: #66791

On Linux, recursive fs.watch() is the JavaScript watcher in lib/internal/fs/recursive_watch.js. Since #65486 it handles each inotify event with a stat()/lstat() of the entry it names, and calls fs.watch() on directories and symlinks that show up later. When one of those calls fails with anything other than ENOENT, the error is thrown inside the FSEvent callback, where no 'error' listener can see it, and the process exits:

Trigger	Thrown from	v24.22.0, v26.9.0, v26.12.0	v24.21.0, v26.4.0, v26.8.2
watched directory becomes unreadable (chmod 000)	lstatSync() in #onFolderEvent()	uncaught EACCES, exit 1	'error', keeps running
new directory already unreadable when its event is handled	fs.watch() in #watch()	uncaught EACCES, exit 1	'error', keeps running
new symlink into an unreadable directory, or a symlink loop	fs.watch() in #watch()	uncaught EACCES / ELOOP, exit 1	'error', keeps running
watched directory replaced by a file while events for its entries are queued	lstatSync() in #onFolderEvent()	uncaught ENOTDIR, exit 1	keeps running, no event

What this changes:

• The statSync()/lstatSync() calls in #onFolderEvent() and #onEntryEvent() now report failures through 'error', the same way #scanFolder() already handles readdirSync() failures (fs: ignore deleted dirs in recursive watch scan #63686). ENOTDIR from lstatSync() is treated as the entry being gone, which is what statSync() with throwIfNoEntry: false and #scanFolder() already do.
• #watch() now gets the initial flag its callers already have. After the initial scan, a failure to watch a directory or symlink is reported through 'error' and the entry is dropped, so a later event about it (for example the chmod that makes it readable again) picks it up. During the initial scan, errors still propagate out of fs.watch(), as fs: fix recursive watch error handling #65635 and fs: handle recursive watch setup races #65699 intended.

Why 'error' instead of silently forgetting the entry: the watcher can no longer see inside that directory, the native watchers report this kind of failure through 'error' too, and long-running consumers such as file-watching daemons need to know. Without an 'error' listener the emitter still throws, like any other FSWatcher error.

I didn't add a #closed check before the new emit('error') calls: both handlers return early once the watcher is closed, and so does #watch(). The only code that can run in between is a user-supplied ignore function, which can already lead to 'change' being emitted after close().

Tests (each one crashes the process without this change and passes with it):

• test-fs-watch-recursive-unreadable-dir.js: a directory made unreadable while watched, and a directory that is already unreadable when its creation is handled and is picked up once it becomes readable. Skipped as root.
• test-fs-watch-recursive-dir-replaced-by-file.js: the ENOTDIR case; no 'error' is expected.
• test-fs-watch-recursive-symlink-loop.js: a symlink loop created while watching; 'error' with ELOOP is expected. This covers the symlink branch of #addEntry().

Checked locally on a build of main (Ubuntu on WSL2): the new tests fail before the change and pass after it, 10 runs in a row; tools/test.py 'parallel/test-fs-watch*' 'sequential/test-fs-watch*' passes (49 tests); make lint-js is clean.

v24.22.0 has the same code, since #65486 landed there too, so this should go to v24.x as well.

I used an AI coding assistant to help investigate this and draft the change. I reproduced the crashes myself, reviewed the diff, and ran the tests and lint locally.

[github-actions]

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

• the guide for first-time contributors
• the contribution and automation policies
• the pull request guide
• the AI use policy
• the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.