More resilient error handling in SymlinkWatcher

[fredrikekelund]

Related issues

• Fixes RSM-3516

How AI was used in this PR

Claude drove the implementation based on logs and error context that I gathered.

Proposed Changes

I had observed issues on Windows with the SymlinkWatcher emitting uncaught exceptions on Windows when Studio was applying a blueprint to a site. This killed the site process, which obviously is a pretty bad experience for users. This PR fixes that by:

1. Passing persistent: true to chokidar. Per the docs, this option has limited effect, but it also attaches an error listener to the underlying FS watcher, which prevents Node from throwing uncaught exceptions.
2. Re-attaching the chokidar watcher (with exponential backoff) on error events. On Windows, the theory is that this happens when the wp-content dir itself is removed (or considered to have been removed by the kernel)

Testing Instructions

1. Be on Windows
2. npx cross-env STUDIO_RUNTIME=native-php npm start
3. Create a new site
4. Select the "Non-Profit Organization" blueprint
5. Ensure that the site creation completes successfully and that the server isn't killed in the process

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing a6885ff vs trunk

app-size

Metric	trunk	a6885ff	Diff	Change
App Size (Mac)	1375.99 MB	1375.99 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	a6885ff	Diff	Change
load	1474 ms	1470 ms	4 ms	⚪ 0.0%

site-startup

Metric	trunk	a6885ff	Diff	Change
siteCreation	8550 ms	8560 ms	+10 ms	⚪ 0.0%
siteStartup	4928 ms	4925 ms	3 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)