(fs): retry atomic renames on Windows EPERM/EBUSY/EACCES through one helper #900

Problem

• Measured (main 2fb1779). Six write-to-temp-then-rename sites, each with a bare fs.renameSync and no retry:
  • project-remap.js:24-25 (JSONL rewrite on remap; on error unlinks the temp and throws)
  • remote-mirror.js:50-52 (writeManifest, fixed .tmp name, no catch)
  • remote-transport.js:357 (scp fetch) and :412 (range append) — on error: temp removed, log.warn, fetch counted failed
  • schedule-runner.js:656 (setScheduleEnabled, rename injectable, returns { ok:false })
  • trigger-watcher.js:1080 (result file; on error safeLogError, the result is lost)
  • (session-index-store.js:28-30 is a one-shot legacy DB relocation, not an atomic write; out of scope.)
• Assumed (Windows behaviour, not reproduced here). MoveFileEx onto an existing file fails with EPERM/EACCES/EBUSY while another process holds the destination open without FILE_SHARE_DELETE (Defender, the search indexer, an editor, a non-Node reader of a trigger result). Node's own readers share delete and do not cause it. graceful-fs (already in node_modules transitively) retries such renames for this reason.
• Measured: no occurrence logged. main.log + main.old.log (2026-10-27 21:44 → 2026-10-29 23:55) contain 0 EPERM/EBUSY. The risk is real in principle, its frequency unknown.

Scope

• One atomic-write.js exporting renameWithRetry(src, dest, { attempts, delays, sleep, rename }) (sync, since all callers are sync; bounded backoff, e.g. 10/30/100/300 ms, total < 0.5 s; retry only EPERM, EACCES, EBUSY on win32; other codes and other platforms rethrow at once) and optionally writeFileAtomic(dest, data, opts) with a unique temp name (remote-mirror.js reuses a fixed .tmp).
• Route the six sites through it; keep each caller's existing error handling.
• Context note in .ai/contexts/ (session-cache or trigger-watcher, where the sites are documented).

Out of scope

• Async rewrites of the callers; the legacy DB relocation; changing what callers do after a final failure.

Acceptance

• Red first: unit test with an injected rename that throws EPERM twice then succeeds → the call returns and rename was called 3 times; with ENOENT → throws after 1 call; with persistent EPERM → throws the last error after the bounded attempts. Fails today (module absent).
• A Windows-only integration test holds the destination open with a non-sharing handle from a child process the test spawns, releases it after 50 ms, and checks the rename lands.
• Each of the six sites has a test proving it uses the helper (injected rename or module stub).

Notes

• Sync sleep: Atomics.wait on a SharedArrayBuffer, never a busy loop; the main-process callers block the event loop for at most the bound.
• Tests write only in their own temp dirs, never in ~/.switchboard or the triggers dir of the user's running Switchboard, and never kill anything; if a helper process is needed, stop it by its PID, never by image name.
• Related: audit 2026-10-29 recommendation 6 (it counted 5 sites; 6 found).