fix: accept Windows script paths and start the daemon from a real install (#23)

Two independent Windows/production defects reported in #22.

browser_run_script rejected every absolute path on Windows. The allowed-root
check compared with a hardcoded `${root}/`, but path.resolve returns
backslash-separated paths there, so a file inside os.tmpdir() was refused even
though the rejection message listed tmpdir as allowed. Decide containment with
path.relative instead: it is separator-agnostic and carries each platform's own
case rules, so it also accepts a differing drive-letter case that a path.sep
patch would still reject. Escapes via `..` and sibling directories sharing the
root's name prefix stay rejected, as before.

The daemon could not start under `npm omit=dev`: it is spawned through tsx,
which was declared only as a dev dependency. Moving tsx to dependencies is not
enough on its own — pi installs extensions into one flat hoisted tree, so tsx
lands beside the package and the fixed <pkg>/node_modules/.bin/tsx lookup still
misses, falling through to an `npx tsx` that resolves against the wrong cwd and
dies against stdio: "ignore". Resolve the CLI entry with Node's own resolver,
which walks up to the hoisted copy. That removes the shell entirely, and with it
the Windows .cmd shim, windowsVerbatimArguments, and the manual quoting that
paths containing spaces needed.

Both fixes live in platform-branching code, so their tests are registered in the
three-OS CI matrix that already exists for that purpose — a Linux-only run
cannot exercise either one.

1 files changed, 11 insertions, 7 deletions

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index f307368..9550d94 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -35,14 +35,16 @@ jobs:
       - name: Verify npm package
         run: npm pack --dry-run > /dev/null
 
-  # Profile discovery and pinning are the only parts of the harness whose
-  # behavior differs per operating system: user-data-dir locations, how the
-  # running browser is identified, and whether a --profile-directory launch is
-  # handed to the running browser by Chromium's ProcessSingleton. Chromium's
-  # source says all three behave the same everywhere; this job is what turns
-  # that into evidence on real macOS and Windows machines.
+  # The parts of the harness whose behavior differs per operating system:
+  # profile discovery and pinning (user-data-dir locations, how the running
+  # browser is identified, whether a --profile-directory launch is handed to the
+  # running browser by Chromium's ProcessSingleton), script-path containment
+  # (separators and case rules), and how the daemon process is spawned.
+  # Chromium's source and node:path's docs say these behave as expected
+  # everywhere; this job is what turns that into evidence on real macOS and
+  # Windows machines.
   profiles:
-    name: Profiles (${{ matrix.os }})
+    name: Platform behavior (${{ matrix.os }})
     runs-on: ${{ matrix.os }}
     strategy:
       fail-fast: false
@@ -70,6 +72,8 @@ jobs:
           npx tsx test/profile/list-test.ts
           npx tsx test/profile/store-test.ts
           npx tsx test/profile/browser-process-test.ts
+          npx tsx test/util/paths-test.ts
+          npx tsx test/util/daemon-socket-test.ts
         shell: bash
 
       # The runner images ship Google Chrome on all three platforms. Linux has