Summary

Fixes the Windows browse lifecycle path so status/stop do not accidentally start or leave behind a headless daemon, and hides gstack-owned helper subprocess windows on Windows.

What changed

• make browse status passive by reading the state file and querying a new authenticated /status endpoint instead of calling ensureServer()
• make browse stop operate on an existing state file without autostarting a daemon
• add windowsHide: true to gstack-owned Windows subprocess launches, including taskkill, Node daemon launch, Bun polyfill subprocesses, and cookie-import helpers
• shorten the default Windows headless idle timeout to 5 minutes while keeping non-Windows at 30 minutes
• add focused CLI lifecycle tests that verify passive status behavior without booting the full browser integration suite

Why

On Windows, browse commands can surface short-lived PowerShell/console windows while agents are active. Separately, browse status previously went through the normal server setup path, so checking whether a daemon existed could create one. That made stale or stray daemon investigation harder and could keep the chrome-headless-shell process cycling after a session appeared to be done.

This addresses the behavior reported in #1835 and #1784.

Validation

• bun test browse/test/cli-lifecycle.test.ts browse/test/cli-setsid-daemonize.test.ts browse/test/cookie-import-browser.test.ts
• git diff --cached --check

I also smoke-tested the patched local install on Windows before extracting this PR: browse status with no daemon stayed stopped, browse goto https://example.com launched successfully, and browse stop removed the daemon and child headless Chromium processes.

Notes

This PR only changes tracked gstack source. I intentionally did not include a direct local patch to node_modules/playwright-core; if Playwright's internal process launcher still contributes visible windows after this, that should be handled as a separate build-time patch or upstream Playwright issue.