Fix Windows E2E hangs: restore per-command CLI shutdown and isolate the daemon per home

[gavande1]

Related issues

• AINFRA-2588 (Investigate Studio Windows E2E hangs in Buildkite)
• Combines Test restoring per-command CLI shutdown handling #4070 and Isolate the process-manager daemon per home on Windows #4061 (its own commits only — this branch deliberately excludes Fix Windows E2E hang: bound daemon requests and reap leaked daemon between sessions #4041, which Isolate the process-manager daemon per home on Windows #4061 is stacked on) on latest trunk

Proposed Changes

Windows E2E has been broken since June 29 by two independent regressions that merged the same day, which is why earlier single-PR reverts never fixed it:

1. Extract the CLI spawn helper to @studio/common #3954 caused the 3-hour hangs. Its killAll() on will-quit runs one listener after the quit handler that spawns site stop --all, so the stop command is killed before it can stop any site. Sites leak into the machine-global process-manager daemon until its capacity cap is exhausted and every subsequent site creation times out. Fixed here by restoring per-command CLI shutdown handling (Test restoring per-command CLI shutdown handling #4070): each CLI child registers its own quit-time kill handler when spawned, so the quit-time stop survives. Verified on CI: quit-time stops complete in under a second (previously a 20-second timeout on every session) and zero capacity errors.

2. Fix native PHP sites loading assets from remote siteurl/home (STU-1925) #3988 caused the ~25 test failures. It made every native-PHP site start pass an auto_prepend_file (the site-url prepend that loads reprint's runtime, including the SQLite loader) as an unquoted -d directive. On CI Windows agents the file lives under an 8.3 short path (C:\Users\BUILDK~1\...), and the unquoted ~ fails PHP's INI parsing (syntax error, unexpected '~' in Unknown on line 4 — visible in the daemon logs this PR now uploads). PHP drops the directive, WordPress boots without its SQLite driver, and every page renders an instant database error — which is why browser-driven tests saw non-WordPress pages while the app's own UI worked. Fixed by quoting the value like every other path directive. This never reproduced on developer machines because short usernames don't get 8.3-mangled.

Also included:

• Isolate the process-manager daemon per home on Windows (Isolate the process-manager daemon per home on Windows #4061): the daemon pipe is scoped per home directory instead of machine-global, so even if a session leaks it cannot poison other sessions or other builds on the same agent. Includes that branch's daemon-log diagnostics (adjusted here to keep the daemon home in a short tmp path — the original diagnostic placed the daemon's Unix socket under a long test-results path, which exceeds the macOS/Linux socket path limit and broke every site creation with connect EINVAL; logs are now copied into test-results at cleanup instead) and the PHP-binary re-download fix.
• CI reporting fixes: one combined "E2E Tests" GitHub status for all platforms (previously last-writer-wins let a green mac job mask a failing Windows job), a 100-minute job timeout, a cancellation trap so a timed-out job cannot record exit status 0 and turn the build green, and per-test/per-action log streaming with failure screenshots and daemon logs as artifacts.

Testing Instructions

• CI (Windows E2E): the job should finish well under the 100-minute cap with no site stop --all command timed out lines, no CAPACITY_LIMIT_REACHED errors, and no syntax error, unexpected '~' lines in the daemon logs. Browser-driven tests (blueprints, wp-admin shortcuts, homepage) should pass.
• GitHub status: the "E2E Tests" context stays pending until mac, Windows, and Linux all finish, then reports one combined result.
• Unit: npm test -- apps/cli/tests/ (817 tests pass).

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[gcsecsey]

Thanks for creating this, I think it makes sense to land these fixes together, and continue investigating the failing tests separately. 👍

[fredrikekelund]

#4061

This does not seem to be the cause of the failing tests. My two cents are that we should zero in on what's causing the failures (which you appear to have done excellently with #4070 and the bug fix for #3988), ship the fixes, and only then look into amendments.

The failing E2E tests tell us something is broken in production, and there's always a risk that we'll tape over real issues if we change how they work while trying to fix an outage.