fix(session): retry zarr chunk-rename on Windows transient file locks

[wizzardkyd96]

Problem

On Windows, session recording crashes mid-session with PermissionError (WinError 5 / 32) raised from deep inside zarr's chunk write.

Session.append() → zarr.Array.append() commits each chunk by writing a temp file and atomically renaming it over the destination (zarr.storage._local._atomic_write). On POSIX that rename is atomic and never fails. On Windows the underlying MoveFileEx fails whenever another handle to the file is still open at that instant — an antivirus scan of the just-written chunk, the Search indexer, or simply the OS not having released the handle the microsecond after close() returned.

It's intermittent (a timing collision, not a concurrency bug), but a high-rate multi-stream recording hits it reliably: every append grows the arrays, each trailing-chunk rewrite is another rename, and losing the race once crashes the whole recording.

Why it can't be fixed at Session.append

zarr.Array.append resizes the array (persists the new shape) before writing the chunk data. If a chunk rename fails after the resize, retrying append would write at the wrong offset and corrupt the array. So the retry has to live at the rename itself.

Fix

This is the write-path counterpart to the existing _robust_rmtree, which already retries on the same Windows file-handle lag during teardown. _install_windows_zarr_atomic_write_retry() wraps zarr.storage._local._atomic_write with a bounded exponential back-off (10 attempts, 50 ms × attempt, with a gc.collect() between tries to drop lingering handles).

• Windows-only — sys.platform != "win32" returns immediately; complete no-op on POSIX.
• Guarded — wrapped in try/except, so if zarr's internals ever move it degrades to a no-op and can never break import.
• Preserves the original exclusive / _safe_move path.

Root cause / upstream note

The actual defect is in zarr (_atomic_write has no Windows-lock resilience), and it's unfixed as of the latest zarr (3.2.1) and on zarr's main. The proper long-term fix belongs there; this shim keeps MyoGestic recording robust until a fixed zarr is released, at which point the wrapper is harmless.

Testing

Verified against real zarr 3.2.1 by injecting forced transient PermissionErrors into the rename: 10 forced failures were retried and the resulting array came back with the exact expected shape and byte-for-byte intact data. No-op confirmed on non-Windows (early return).