fix(hooks): rotation falls back to truncate-in-place on Windows

The Rust agent flagged this real concern: on Windows, the tailer's
open `File` handle can keep `fs.renameSync(out → out.1)` from
succeeding. First time the producer tries to rotate while the
inspector is tailing, the rename throws — and our previous catch-all
swallowed the error so the file would just keep growing.

Try rename first (preserves history in .1 on POSIX). If rename
fails (Windows file lock), truncate-in-place to 0 bytes. The
inspector's tail mode already handles truncation-as-rotation via
the `metadata.len() < read_offset` check, so the consumer side is
unchanged.

Tradeoff: on Windows we lose the .1 archive across rotations, but
events keep flowing — that's the right priority.

Author: klaiderman

scripts/hooks/claude-code-emit.mjs

@@ -83,12 +83,23 @@ function rotateIfLarge() {
     const st = fs.statSync(outPath);
     if (st.size <= MAX_BYTES) return;
     const backup = `${outPath}.1`;
+    // Try rename-swap first (preserves history in .1). On Windows, this
+    // fails while the inspector has the file open for tailing. Fall back
+    // to truncate-in-place — the tailer's `metadata.len() < read_offset`
+    // detection treats truncation as rotation, so the consumer side is
+    // unchanged. We lose the .1 archive in the truncate path; acceptable
+    // tradeoff vs. dropping events because rename was blocked.
     try {
       fs.unlinkSync(backup);
     } catch {
       /* fine if missing */
     }
-    fs.renameSync(outPath, backup);
+    try {
+      fs.renameSync(outPath, backup);
+    } catch {
+      // Rename blocked (most likely Windows + open handle). Truncate.
+      fs.truncateSync(outPath, 0);
+    }
   } catch {
     /* file doesn't exist yet — nothing to rotate */
   }