Headed mode fails to launch on macOS 26.4.1 (Tahoe stable): "Mach rendezvous failed" before any page loads

## Summary

`browse --headed` (and the equivalent `$B connect` / `/open-gstack-browser` flow) **fails immediately on launch** on macOS 26.4.1 (Tahoe stable). Chromium child processes cannot establish Mach IPC with the Bun-compiled gstack server, and `launchPersistentContext` reports the context closed before any page is reached.

This is **not** the 15s watchdog crash from #867 / #1006 / #870 / #943 (all fixed via #868 / v0.15.15.1) — those covered a different failure mode where the headed window stayed alive for ~15s before being killed. This one is an *immediate* failure during the Chromium spawn handshake.

**Headless mode works perfectly**, including all v1.28.0.0 features (`--proxy`, `download --navigate`, `prettyscreenshot --cleanup`, `ux-audit`, `cleanup`, `/scrape skill run`). The bug is specific to the headed launch path.

## Environment

- **macOS:** 26.4.1 (Tahoe stable, build 25E253)
- **gstack:** 1.28.0.0 (commit 443bde0)
- **Hardware:** Apple Silicon (arm64)
- **Binary:** `~/.claude/skills/gstack/browse/dist/browse` (Bun-compiled)
- **Playwright Chromium:** chrome-mac-arm64 build 1208 (`Google Chrome for Testing`)

## Reproduction

```bash
B=~/.claude/skills/gstack/browse/dist/browse
$B disconnect
$B --headed status
```

## Output

```
[browse] Starting server in headed mode...
[browse] Server failed to start:
[browse] Buffer flush failed: lastConsoleFlushed is not defined
[browse] Buffer flush failed: lastConsoleFlushed is not defined
[browse] Failed to start: persistentContext: Target page, context or browser has been closed
Browser logs:

/Users/.../ms-playwright/chromium-1208/chrome-mac-arm64/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing [...flags...] --remote-debugging-pipe about:blank
pid=90822
[pid=90822][err] WARNING:third_party/crashpad/crashpad/util/numeric/in_range_cast.h:38] value -634136515 out of range
[pid=90822][err] [90837:1631406:.../shared_memory_switch.cc:273] Mach rendezvous failed, terminating process (parent died?)
[pid=90822][err] [90838:1631421:.../shared_memory_switch.cc:273] Mach rendezvous failed, terminating process (parent died?)
[pid=90822][err] [90829:1631318:.../net/socket/ssl_client_socket_impl.cc:918] handshake failed; returned -1, SSL error code 1, net_error -3
```

The Chromium child renderer/utility processes immediately fail their Mach IPC handshake with the parent and exit. `launchPersistentContext` then reports the browser closed before any page can be reached.

## Diagnostic angle

The `Mach rendezvous failed, terminating process (parent died?)` pattern points at Chromium's macOS shared-memory switch failing to associate child PIDs with the parent. On Bun-compiled binaries this is plausibly related to how Bun's `bun build --compile` wraps process metadata in a way macOS 26's tightened security policies / Mach namespace handling no longer accepts. Headless mode works because the renderer uses a different IPC bootstrap path that doesn't go through this rendezvous step.

Two minor quirks visible in the output that may or may not be related:
- `Buffer flush failed: lastConsoleFlushed is not defined` printed twice on every headed-startup failure
- `value -634136515 out of range` from `in_range_cast.h` — looks like a Chromium-internal warning, but the negative value suggests an integer overflow somewhere in the parent-handle plumbing

## What's ruled in/out

- ✅ Headless mode works end-to-end
- ✅ Reproduces deterministically on every `$B --headed` invocation
- ❌ Not the 15s watchdog issue (#867, #1006, #870, #943 — all fixed via #868)
- ❌ Not extension-related (Chromium dies before extensions load)
- ❌ Not profile-corruption (same behavior on `rm -rf ~/.gstack/chromium-profile`)

## Possibly related upstream

- https://github.com/microsoft/playwright/issues/34693 (macOS 15.3 Sequoia headed crash) — different symptom, same family
- Likely originates in Chromium itself: `base/memory/shared_memory_switch.cc:273`

## Suggested mitigations (in order of effort)

1. **Detect macOS 26.x at runtime and warn** before attempting `--headed` so users aren't blindsided
2. Document `chrome-devtools MCP` and external Chromium-with-extension as the macOS 26 workarounds
3. Investigate whether running the daemon under Node (via `server-node.mjs`) instead of the Bun-compiled binary changes the headed-launch outcome — would localize the issue to the Bun compile path

I'm happy to test patches on macOS 26.4.1 when something lands.

---

Filed alongside #1378 (separate `prettyscreenshot --hide` argument-parsing bug found during the same v1.28.0.0 verification pass).