fix(browse): respect GSTACK_CHROMIUM_PATH in headless mode

[mvanhorn]

Summary

GSTACK_CHROMIUM_PATH is only respected in launchHeaded() (browser-manager.ts:270) but not in launch() (browser-manager.ts:183). Skills like /qa use headless mode by default, so setting GSTACK_CHROMIUM_PATH has no effect when the bundled chromium_headless_shell fails on NixOS and other non-FHS distros.

Changes

Read GSTACK_CHROMIUM_PATH in launch() and pass it as executablePath to chromium.launch(), matching the existing pattern in launchHeaded().

browse/src/browser-manager.ts: 3 lines added.

Testing

bun test passes (665 pass across skill validation and gen-skill-docs). The change mirrors the existing env var handling in launchHeaded() at line 270.

Fixes #906

This contribution was developed with AI assistance (Claude Code).

[jbetala7]

This specific headless GSTACK_CHROMIUM_PATH gap appears fixed on current main now. The merged maintainer wave #1642 / v1.43.2.0 carries the headless executablePath: process.env.GSTACK_CHROMIUM_PATH || undefined change in browse/src/browser-manager.ts, and also includes the later isCustomChromium() guard so baked-extension Chromium builds do not double-load the extension.

Given that, I would treat #1642 as the canonical shipped fix for the browser-manager part of this PR. If issue #906 still has a remaining setup/install angle, it likely needs a fresh narrow PR against current main rather than this older branch.

[mvanhorn]

Good catch @jbetala7 — confirmed browser-manager.ts:444 on current main carries executablePath: process.env.GSTACK_CHROMIUM_PATH || undefined, plus the isCustomChromium() guard. #1642 supersedes this PR; closing. If #906 still has a remaining install/setup angle I'll spin up a narrower PR against current main. Thanks for the heads-up.