v3.0.5 - Reliability and hardening across the MCP and CLI launch paths

Fixed

• MCP tool errors now set isError: true on the CallToolResult (#44). Thrown handler errors were returned as ordinary text, so clients recorded failures as successes and loop breakers keying on the error flag never engaged (observed as ~300 consecutive identical failing calls in one agent session). The one in-band error-string return (extract's element-not-found) now throws, with identical user-visible text; the DialogRefusal synthetic response deliberately stays non-error.
• CHROME_WS_BROWSER is honored by the MCP launch path (PR #41, partially addresses #40). It was documented and honored by the CLI but silently ignored by chrome-process.js. A set-but-missing path warns on stderr and falls back to auto-detection; the not-found error names the override.
• The MCP server exits when its host goes away instead of leaking (PR #42, partially addresses #40). Shutdown on stdin end/close, transport close, and a 30s ppid watchdog; exiting releases the profile lock so the next server reclaims the profile and reconnects to the existing Chrome instead of spawning another.
• chrome-ws start honors CHROME_EXTRA_ARGS via the shared buildChromeArgs() helper (PR #37, partially addresses #35). CLI start stays headed by default; the shared baseline flags mean headless-Linux-as-root works with no env var at all.
• The schema-collapse dead-Chrome test faked only isPortAlive, so its kill path SIGTERMed whatever real process held port 9222 (intermittently killing the smoke test's Chrome mid-suite) and its restart path spawned and leaked a real Chrome with profile test. The harness now fakes every process-reaching helper.
• Chrome's sandbox stays on except where it cannot work (#45). --no-sandbox was unconditional in the shared launch flags; it is now emitted only when sandboxDisableNeeded() detects root or a container (/.dockerenv, /proc/1/cgroup markers). CHROME_EXTRA_ARGS still force-adds it anywhere.
• A Chrome spawn failure (async 'error' on the ChildProcess — e.g. CHROME_WS_BROWSER pointing at the .app bundle instead of the inner binary) no longer crashes the MCP server as an uncaught exception; startChrome rejects with the binary path in the message (#46).
• Host-lifecycle hardening (#47): close/error handlers moved from transport.onclose (overwritten at connect() by older SDK 1.x versions within our range) to the version-stable server.server.onclose/onerror; the ppid watchdog interval is configurable via CHROME_WS_PPID_WATCHDOG_MS (0 disables); an error-driven transport close (oversized frame with a live host) exits 1 instead of reporting success. Both previously untested shutdown signals now have behavioral tests.
• All tests now point XDG_CACHE_HOME at per-run temp dirs, so the suite (including crashed runs) can no longer delete real profile meta files for live MCP sessions or litter the user's real cache directory with test profiles.
• chrome-ws start failure reporting (#35, remaining asks): Chrome's stderr is captured to a tempfile and surfaced on failure (previously discarded via stdio: 'ignore', so e.g. Running as root without --no-sandbox is not supported. vanished); Chrome exiting before the port poll is reported as Chrome exited with code N before opening the debug port instead of the misleading "remote debugging not accessible"; a still-running Chrome with an unresponsive port gets its own distinct message; and a spawn failure (e.g. CHROME_WS_BROWSER pointing at a directory) produces a clean one-line error instead of an uncaught exception.