e2e: browser-readonly-catalog bronze bundle fails on CI (shared-Chrome gate denies the fixture host) #30

Summary

The TestBronzethread/browser-readonly-catalog e2e bundle fails on CI. It is pre-existing and isolated — surfaced now only because the browser-toolbox stacked PRs (#24–#28) are the first time the feature has run e2e on CI (it was developed on worktree branches, which don't trigger CI). Every other suite is green: unit, integration, format, frontend, site, toolchain-images, and every other e2e scenario (incl. steelthread and the other browser bundles).

Failure

Run: https://github.com/authzed/openagentprimitives/actions/runs/38110312172 (e2e job)

--- FAIL: TestBronzethread/browser-readonly-catalog
  llm step 3: "host host.docker.internal is not allowed by browser toolbox web (rule: blocked by egress policy)" does not contain "loaded"
  llm step 4: "[e1] document \"\"\n\npage 1 of 1" does not contain "BRONZE-FARES-TABLE"

Step 3's web_navigate to the test fixture (host.docker.internal) is denied by the shared-Chrome gate's egress proxy, so step 4's web_read sees an empty page.

What's going on

• The bundle's toolbox is mode: allowlist with a placeholder site (example.com); the real fixture host (host.docker.internal) is supposed to be appended automatically by setupBrowserFixture for an allowlist-mode toolbox (see test/e2e/threadrun/driver.go), and that effective spec feeds both the runner pre-check and testbrowser.StartGate's policy.
• At runtime the runner's own navigate pre-check allows host.docker.internal (its effective sites carry the appended host — t.decide(host) returns an empty rule), but the gate proxy denies it during navigation (tools.go proxy-denial path → generic "blocked by egress policy").
• So the gate's effective policy and/or dialer is not admitting host.docker.internal for this specific bundle, while the two passing browser bundles (browser-consequence-gate, browser-login-secret-source) explicitly list host.docker.internal and are interaction: act (vs this one's interaction: readonly, referencesToolbox=false).

Likely area

The auto-append → browserPolicyFromSpec → StartGate path (shared-Chrome single global egress proxy + the SetDialContextForTest host.docker.internal→loopback mapping), specifically for an interaction: readonly / class-does-not-reference-toolbox bundle. A naive "list the host explicitly" is suspect because the gate already receives the appended host yet still denies, so the fix should confirm why the gate's policy/dialer rejects it on CI's Docker environment (where host.docker.internal resolves to a private host-gateway IP).

Not a regression

Harness code (pkg/tools/browsergate, test/testbrowser, test/e2e/threadrun/driver.go) is unchanged by the stacked-PR work; the bundle/manifest is unchanged; and the failure reproduces identically on all five phase PRs including the base (phase A), whose browser code carries none of the stack's later fixes.