Add CLI integration test for site start/stop lifecycle

[gcsecsey]

Related issues

• Fixes STU-1868
• Builds on Add CLI integration test for site create (custom name, domain, HTTPS) #3947 (the site create integration test + e2e harness) and complements the UI suite in Add Site Management UI integration tests #3950

How AI was used in this PR

I used Claude to write the test and the harness changes, and traced the daemon connection failures to a Unix socket path length limit. I reviewed the diff, ran the suite on nodes 22 and 24, and confirmed that runs are isolated, with no orphan daemons/servers and no temp-dir leaks.

Proposed Changes

We're migrating the legacy blueprint-based start/stop test cases to the CLI integration approach. The existing start.test.ts / stop.test.ts unit tests mock the daemon and server manager. This PR instead boots a real WordPress server through the process-manager daemon and verifies the live running state via site list --format json, so it actually exercises the daemon -> server -> port lifecycle.

• Adds an e2e-tagged suite that creates a site with --no-start. It runs in the slower (release/manual) suite, not on every PR.
• Updates the harness to prevent the tests affecting local sites. The lifecycle commands talk to the process-manager daemon, and the cleanup step stop --all would kill the developer's real running sites. The harness now gives each run its own daemon home via STUDIO_PROCESS_MANAGER_HOME, so runs are fully isolated and parallel-safe. That home is deliberately kept short and under the temp dir: the daemon's control socket is a Unix domain socket, and nesting it under the studio-cli-e2e-<uuid> root path overflows macOS's 104-char socket path limit. This surfaces as EINVAL on node 24 and as an indefinite connect-retry (hang) on node 22. Windows uses a fixed named pipe, so this isolation is macOS/Linux only.
• The harness also seeds a minimal app.json so the 00-check-studio-compatibility migration returns early. Without it, that migration falls through to the developer's real legacy app data and aborts the CLI, so the suite would pass on CI yet fail on a dev machine with Studio installed. This also retroactively hardens the site create test from Add CLI integration test for site create (custom name, domain, HTTPS) #3947, which carries the same gap.
• Uses --runtime sandbox to stay hermetic. The native PHP runtime drives the same lifecycle but downloads its ~25 MB binary into the isolated config dir on the first run. Covering it hermetically needs CI to provision that binary, so native-PHP coverage is a follow-up.

Testing Instructions

1. npm run cli:build
2. npm test -- --tagsFilter='e2e' apps/cli/commands/site/tests/start-stop.e2e.test.ts
3. Expect 2 tests green (starts a site, stops a site).
4. While it runs, confirm it does not disturb sites you have running in Studio, and leaves no orphan processes or temp dirs afterward.

Pre-merge Checklist

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