Windows TCP connection fix (#12) + reloadBeforeEach option

[francislavoie]

Two fixes needed to run tauri-playwright against a real Tauri app on Windows. Both are in packages/test; behavior on macOS/Linux and existing configs is unchanged.

---

1. Connect over TCP on Windows — Fixes #12

Problem. On Windows the Rust plugin can't bind a Unix domain socket, so it falls back to a TCP listener (127.0.0.1:6274 by default, logged as listening on tcp://...). But createTauriTest's tauri mode ignores that: it always builds new PluginClient(socketPath) and, for an already-running app, waits for a socket file that never appears on Windows. So mode: 'tauri' can't connect on Windows at all (the TCP port returned by processManager.start() is dropped — #12).

Fix (fixture.ts):

• Honor the endpoint TauriProcessManager.start() detected ({ tcpPort } | { socketPath }) instead of discarding it.
• For an already-running app on Windows, connect to the TCP port (default 6274, overridable via TAURI_PW_TCP_PORT) rather than waiting for a nonexistent socket file.
• Retry the initial connect for up to 30s so the client tolerates the app still booting.

---

2. reloadBeforeEach option to skip the per-test page reload

Why this was changed. The tauri-mode fixture reloads the page (window.location.href = devUrl) before each test to reset state. That assumes the reload is cheap. On a heavy app it isn't: the reload re-runs the whole app bootstrap (reconnecting sockets, re-initializing services, …), which takes seconds. The fixture then waits only 500ms and issues a waitForFunction eval to check readiness — but that eval lands while the page is still navigating/rebooting, its execution context is torn down before it can invoke pw_result, and the plugin waits out its full 30s eval timeout. The result is a deterministic hang on the first test after a cold launch (the second test's reload targets the same URL and no-ops, so it slips through). This reproduces with zero user interaction.

A single 500ms wait can't cover an arbitrary app's reboot time, and an eval issued mid-navigation can't be cancelled from the JS side (the socket matches responses by order, not id), so there's no clean way to make the reload robust for heavy apps from the fixture alone.

Fix (fixture.ts + types.ts): add reloadBeforeEach (default true, so existing behavior is unchanged). Set it to false to skip the reload — tests then run against the app's current, shared state (reset explicitly where a test needs a clean slate). The readiness waitForFunction still runs, so the page is confirmed ready either way.

createTauriTest({
  devUrl: 'http://localhost:1420',
  mcpSocket: '/tmp/tauri-playwright.sock',
  reloadBeforeEach: false, // heavy app: full reload reboots the runtime
});

---

Testing

• pnpm --filter @srsholmes/tauri-playwright typecheck / build pass (the one typecheck error is pre-existing in ipc-mock.test.ts, unrelated).
• Verified end-to-end on Windows 11 against a real Tauri v2 app (WebView2): with (1), mode: 'tauri' connects over TCP and drives the live webview; with reloadBeforeEach: false, the suite runs green in ~2.5s where it previously hung 30s and failed the first test on every cold launch.

🤖 Generated with Claude Code