test(windows): stop the cross-process test starving itself on a loaded runner

The test ran 100 rounds a side, both taking the lock, while a reader thread
hammered the same file. Production allows a 2s wait with a 50ms poll, which
suits a UI that writes on a click but starves under that much contention: a
waiter that loses the race after each poll can exceed the budget, and the
acquire then fails by design. That is what turned main red on the merge,
not a lost update.

24 rounds a side keeps the property under test and the harness stops being
the thing that fails. Measured on this machine, ten runs each way: the test
still fails 10 out of 10 with CB_TRAY_XPROC_NOLOCK=1 and passes 10 out of
10 with the lock, so it detects the bug exactly as reliably as before.

The production budget and poll are untouched. If sustained contention ever
becomes a real workload rather than a test, the poll is the thing to
revisit, not the budget.

windows/src-tauri/src/dock.rs

@@ -2052,7 +2052,13 @@ mod tests {
         // A key neither side writes, to prove the merge preserves it through all the churn.
         fs::write(&dock_file, "{\"other\":\"keep\"}").unwrap();
 
-        let iters: u32 = 100;
+        // 100 rounds a side, both taking the lock, while a reader thread hammers the same
+        // file. The production wait budget is 2s with a 50ms poll, which is right for a UI
+        // that writes on a click but starves under this much contention: a waiter that keeps
+        // losing the race after each poll can exceed 2s on a loaded runner, which is what
+        // reddened main rather than any lost update. Fewer rounds keep the property under
+        // test and stop the harness from being the thing that fails.
+        let iters: u32 = 24;
         let nolock = std::env::var("CB_TRAY_XPROC_NOLOCK").ok().as_deref() == Some("1");
 
         let mut child = match Command::new("node")