Windows: session catalog save always fails on 0.6.0/0.7.0 (directory fsync EPERM)

Summary

On Windows, every operation that persists sessions (session new, execute with a new session, etc.) fails on 0.6.0 and 0.7.0 with:

Could not write Browser Control session catalog at C:\Users\<user>\.browser-control\relays\19989\sessions.json

doctor/status (read-only) are fine. 0.5.1 works. This makes 0.6.0/0.7.0 unusable on Windows.

Environment

• OS: Windows (win32)
• Package: @opencode-ai/browser-control@0.7.0 (also reproduced the broken save() in 0.6.0 sources)
• Node: v24.20.0 (engines floor >=22.19.0 satisfied)
• Last working version: 0.5.1

Repro

browser-control execute --json 'return { ok: true }'
# => { ok: false, isError: true,
#      text: "Could not write Browser Control session catalog at ...",
#      error: { _tag: "RelayClient.RelayRejected", ... } }

I verified the failing step in isolation with plain Node on the same machine/directory: mkdir, chmod 0o700, temp-file create/write/sync/close/rename all succeed; only the directory-handle sync() fails:

open dir ok
dir sync fail EPERM EPERM: operation not permitted, fsync

Root cause

src/session-catalog.ts SessionCatalog.save() does, after rename():

const directoryHandle = await fs.open(directory, "r")
try {
  await directoryHandle.sync()
} finally {
  await directoryHandle.close()
}

Directory fsync is not permitted on Windows (EPERM), so save() throws for every session write even though the rename() itself succeeded and the catalog file is correct.

This looks like a regression from the durability hardening: tag v0.5.1 still had a renamed fallback (if the rename succeeded and re-read contents match, return success despite a later failure), while tags v0.6.0 and v0.7.0 no longer contain it (checked src/session-catalog.ts at refs/tags/v0.5.1 vs v0.6.0/v0.7.0).

Suggested fix

Restore tolerance for the directory-sync step, e.g.:

• re-add the "rename succeeded + contents verify" fallback from 0.5.1, and/or
• skip/ignore directory-handle sync() failure on win32 (best-effort durability where the OS does not support it).

Workaround

Stay on 0.5.1 on Windows until fixed (verified execute/session persistence works there).

Start in src/session-catalog.ts at SessionCatalog.save() and compare its directory-handle sync handling with the v0.5.1 version. Reproduce the failure with the Windows execute command and verify that session catalog persistence succeeds on win32 while retaining the existing behavior elsewhere.