ci(windows): fix the six remaining failures, then make the Windows leg permanent

[e1010101]

The Windows leg is opt-in behind a windows-ci label because the repo could not be built on Windows at all. #97 fixed the build, #101 the ACL checks, and run 30317780975 narrowed what remained to six failures in four files. Those are fixed here, in the same change that makes the leg unconditional — so it arrives green rather than as a red box everyone learns to ignore, per your ordering.

The plan job is gone and the matrix is inlined, which is what its own comment prescribed once #97 and #101 landed.

---

Two suites held an open SQLite handle while deleting their temp home. browser-operator-authorization and workflow-provenance both initDb() and neither closed it. POSIX unlinks an open file; Windows refuses with EPERM, so rmSync threw out of afterAll and failed the suite for a reason unrelated to anything it tested.

Both now close the database first — that is the actual bug, not the removal. A shared removeTempDir() then adds Node's documented retry/backoff (maxRetries/retryDelay, which cover EBUSY/EMFILE/ENFILE/ENOTEMPTY/EPERM) for handles a test cannot close: a child process the OS has not finished reaping, for instance. The global teardown gets the same treatment — it was throwing the identical EPERM after every test had already passed, which is how a fully green run reports as failed.

activity/performance is skipped on Windows, measured rather than assumed. I raised the hook budget and ran it to find out what was actually there:

• seeding the 100k-row corpus takes ~80s against a 60s hook budget, and
• once past that, the filtered query lands at 343ms against a 300ms budget ({"firstMs":57.8,"middleMs":5.5,"filterMs":343.1,"searchMs":59.8}).

Both are the platform — sqlite durability behaviour plus Defender on the temp directory — not a regression. Relaxing wall-clock budgets to accommodate a slower machine leaves a guard that can no longer catch the regressions it exists for, and the numbers would be tuned to whichever machine happened to run it rather than to the runner. It stays enforced on ubuntu where it is calibrated, and the correctness assertions it also makes (totals, page sizes, the indexed-search hit) are platform-independent and covered there.

The three codex-rollout cases in engine-limits are skipped pending #103. Their stubs are #!/usr/bin/env node files made executable with chmod, and Windows has neither a shebang nor an executable bit, so spawn(bin, …) never starts them. As you noted in #103, fixing the stub alone would make them pass without touching the product bug underneath — so I would rather they come back with real Windows coverage via a .cmd stub, which only becomes possible once #103 is fixed. The skip names the issue.

The root postinstall no longer errors on every Windows install. Taken as tidiness, not as the prerequisite we both thought it was — you were right that the runner disproved that twice.

It is a behaviour-preserving port of the shell one-liner rather than a switch to packages/jinn/scripts/fix-node-pty-permissions.mjs: that script is darwin-only by design (process.platform !== "darwin" → exit 0), so pointing the root script at it would have silently stopped chmodding the Linux prebuild. Every prebuild directory is still visited, missing files and chmod failures are still non-fatal, and Windows exits early.

---

Verification. All four files pass or skip cleanly on Windows 11 / Node 24, and both packages typecheck.

One caveat worth stating plainly: my Windows box is a noisier oracle than the runner — a different subset of unrelated suites fails per full-suite run here (pty-stream's 30s timeout, callback-concurrent-init's "readonly database"), and neither has ever failed on windows-latest across the three runs so far. So the runner's verdict on this PR is the one that counts, and since this change makes the leg unconditional it will run on this PR itself. If anything is still red I will fix it before this merges — it should not land red.

[e1010101]

Green, including the Windows leg, on run 30368772169: unit-tests (windows-latest) pass in 6m14s, alongside ubuntu, typecheck and build.

Since this PR makes the leg unconditional, that result came from the leg this PR turns on, running on this PR — no label, no approval. Green first, then flipped, in the order you asked for.

One of the six was not a test problem

The last failure took three iterations to reach and turned out to be a product bug. callback-concurrent-init starts 16 processes against one registry and one died with attempt to write a readonly database — about one run in five locally, and once on the runner.

The stack put it at journal_mode = WAL in initDb, which is already wrapped in runSqliteBusyRetry. Setting WAL takes a brief exclusive lock to rewrite the header, and when a peer holds the file at that instant SQLite reports SQLITE_READONLY rather than SQLITE_BUSY — a class the wrapper did not recognise. So the retry now covers both, with a longer backoff on Windows.

That is not confined to the test: the gateway, the CLI and session workers all open this database, so a Windows operator running any two at once was exposed to the same race. Retrying a database that is genuinely read-only takes the same bounded wait and throws the identical error, so nothing is masked. Measured 1 failure in 5 runs before, 0 in 12 after.

The other five

• Two EPERM teardowns — a real bug in both suites, not a Windows quirk to tolerate: each opened a SQLite registry and never closed it before deleting its directory. POSIX unlinks an open file; Windows refuses. They close the database first now, and removeTempDir() adds Node's documented retry for handles a test cannot close, such as a child process the OS has not finished reaping. The global teardown had the same defect — it was throwing after every test had already passed, which is how a green run reports as failed.
• activity/performance — skipped on Windows, measured rather than assumed. Seeding its 100k-row corpus takes ~80s against a 60s hook budget, and once that is raised the filtered query lands at 343ms against a 300ms budget. Relaxing wall-clock budgets to fit a slower machine leaves a guard that can no longer catch what it exists for, and the number would be tuned to whichever machine ran it. It stays enforced on ubuntu where it is calibrated.
• The three engine-limits cases — skipped pending [Windows] Engine usage limits are unavailable: bare spawn/execFile of a .cmd shim #103, deliberately not "fixed" by making the stub cross-platform, since you pointed out that would paper over the product bug. fix(windows): spawn engine binaries that are .cmd shims #105 now gives them real Windows coverage instead: their stub becomes a .cmd, the shape npm actually installs, so they exercise the spawn path rather than asserting around it.

postinstall

Swapped, as tidiness only — you were right that the runner disproved it as a blocker, twice. It is a behaviour-preserving port rather than a switch to packages/jinn/scripts/fix-node-pty-permissions.mjs, because that script is darwin-only by design and pointing the root script at it would have silently stopped chmodding the Linux prebuild.

Ordering with #105

Both touch engine-limits.test.ts. If this merges first, #105 drops the skip on rebase; if #105 merges first, the skip here becomes a no-op to remove. Either order works. Worth noting #105 cannot be verified on Windows by CI until this lands, since it does not change the workflow and so only gets the ubuntu leg.