squad init and casting fail on Windows with EPERM: operation not permitted, fsync (dev, since #2066) #2106

What happens

On Windows, squad init on current dev fails before any team is written:

SquadError: Failed to initialize squad: EPERM: operation not permitted, fsync
    at fatal (.../squad-cli/dist/cli/core/errors.js:20:11)
    at .../squad-cli/dist/cli-entry.js:374:13

Casting a team (createTeam → commitCastingRegistryPair) fails the same way.

Repro

mkdir squad-repro; cd squad-repro; git init
node <squad>/packages/squad-cli/dist/cli-entry.js init --no-workflows --no-vscode-default

• Windows 11 Enterprise (build 26200), Node v24.13.0
• dev at 29e69f5; CLI reports 0.13.1
• npm 0.13.1 (Sept 8) is not affected. This is unreleased.

Cause

flushDirectory() in packages/squad-sdk/src/casting/durable-registry.ts (added in 1ea685c, #2066) opens a directory with openSync(dir, 'r') and calls fsyncSync on it. Windows doesn't allow fsync on a directory handle and returns EPERM. It's called from durableReplace and createOwnedDirectory, so every durable casting write goes through it.

CI didn't catch it because squad-ci.yml runs only on ubuntu-latest.

Suggested fix

Directory fsync is a POSIX durability step for the rename. Windows has no equivalent, and the file-level fsync has already happened. Skip it on win32, or treat EPERM/EISDIR/EBADF from the directory fsync as a no-op. Also worth considering: a windows-latest leg for the casting durability tests.