fix(Interceptor): test-profile auto-launch fails while Chrome is already running

[anikinsasha]

Problem

Tools/LaunchTestProfile.sh (Darwin branch) launches the isolated test profile with open -a "$BROWSER" --args …. macOS silently drops --args when the target app is already running — open just activates the existing window. Since the operator's working Chrome is normally open, the test-profile window never opens, EnsureTestProfile.sh polls until timeout, and every browser workflow stops at the isolation gate with the context-not-connected remediation. The skill's own gotchas describe this open-already-running behavior, but the shipped launcher still uses the affected form.

Fix

Invoke the browser binary directly (/Applications/<Browser>.app/Contents/MacOS/<Browser> --profile-directory=… --new-window <url>): Chrome's process singleton forwards the arguments to the running instance, so the profile window opens whether or not the browser was already up. open -a is kept as a fallback when the binary isn't at the expected path (reliable only when the browser isn't running). New optional override: INTERCEPTOR_TEST_BROWSER_BIN.

Also adds preferences.env.example documenting the contract variables the three gate/launch tools source (INTERCEPTOR_TEST_CONTEXT_ID, INTERCEPTOR_TEST_CHROME_PROFILE, optional browser overrides, working-profile deny-list). Today these are discoverable only by reading the scripts, and a wrong variable-name guess fails as "no test profile configured."

Testing

With Chrome already running (working profile window open): before the patch, EnsureTestProfile.sh launches, no window appears, gate times out. After the patch, the test-profile window opens and interceptor contexts shows the pinned context connected in ~6s; the gate prints READY. Fallback path unchanged when the binary is absent. bash -n clean.

[danielmiessler]

Ported to the private source tree with credit: both the direct-binary launch (with the open -a fallback when the binary isn't at the expected path) and preferences.env.example. Funny detail: we'd independently hit the same macOS open … --args-dropping behavior and had a manual operational rule about launching via the binary. Your PR turned that tribal knowledge into code, which is strictly better.

The public repo is generated from private source at release time, so closing here; it ships in the next release, credited in the commit. Thanks for the clear example file too.