fix: scope headed-Chromium profile per project, not machine-wide

[himiaocc]

Summary

Two separate bugs, both causing the same visible symptom (headed browser opens then vanishes within seconds — reported as a persistent crash by a user running two sibling project windows concurrently, both driving a captcha-gated login).

1. Chromium profile shared machine-wide, not per-project

• resolveChromiumProfile() defaulted to a single $HOME/.gstack/chromium-profile, even though each browse daemon is already isolated per git repo root (resolveConfig().stateDir).
• Every daemon restart runs killOrphanChromium() (cli.ts), which reads the profile's SingletonLock and kills whatever PID holds it — no way to distinguish a genuinely dead orphan from another project's live headed window.
• Fix: default now resolves to <project stateDir>/chromium-profile. Also fixed two call sites (browser-manager.ts handoff(), cli.ts chromiumProfileDir()) that had their own hardcoded copies of the old global path instead of going through the shared resolver.

2. Parent-process watchdog was killing handoff() sessions within ~15s (found during verification of fix #1 — turned out to be the dominant cause, reproduces with zero concurrency)

• handoff() transitions an already-running headless daemon to headed mode in-place. BROWSE_PARENT_PID on that daemon was set at its original headless spawn — some short-lived CLI process that's expected to exit almost immediately (headless mode's watchdog branch already tolerates this).
• Once handoff() flips connectionMode to 'headed', the watchdog's next 15s tick took the OTHER branch: "headed + parent gone → shutdown", intended for /pair-agent//open-gstack-browser where BROWSE_PARENT_PID is deliberately a real long-lived owner. Applied to a handoff-transitioned daemon, the already-dead CLI parent triggered a shutdown almost immediately after every handoff succeeded.
• Fix: track whether headed mode was reached via handoff() specifically (BrowserManager.handoffTransition / didHandoffTransition()) and have the watchdog treat "headed via handoff, parent gone" the same as plain headless (stay alive).

Test plan

• bun test browse/test/config.test.ts browse/test/handoff.test.ts browse/test/browser-manager-unit.test.ts browse/test/watchdog.test.ts browse/test/server-factory.test.ts — all pass (config 42, handoff+browser-manager+config combined 81, watchdog 4 incl. new regression test, server-factory 33)
• Verified via git stash that a full bun test browse/test/ run truncates identically on unmodified main — pre-existing test-runner quirk, unrelated to this change
• New subprocess-based regression test in watchdog.test.ts (BROWSE_TEST_FORCE_HANDOFF_HEADED env hook) proving the daemon stays alive when its parent dies while in handoff-headed state
• Real-world verification against a live captcha-gated site: ran handoff, then waited 75s (5 watchdog ticks) checking status + actually driving the browser with text — same PID throughout, still headed, still responsive. (First verification pass only checked the immediate handoff() return value and missed bug refactor: reorganize codebase into modular structure #2 entirely — this is the corrected, patient verification.)

🤖 Generated with Claude Code

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here