fix(server): start ACP MCP bridge in self-contained runtime

[pekth]

What changed

The ACP adapter now omits the duplicated server entrypoint when the T3 executable is itself the self-contained runtime. Script-based Node and Electron launches keep the existing command vector. A focused adapter regression covers the self-contained path.

Why

Antigravity could not initialize the injected t3-code MCP server because the self-contained runtime parsed its own executable path as an ordinary CLI positional argument. The bridge process closed before MCP initialize completed.

Verification

• 117 focused adapter and MCP bridge tests passed
• Targeted format and lint passed
• Scoped server typecheck passed
• Isolated preview Antigravity readback and accepted-execution tasks completed with gemini-3.8-flash-medium
• Accepted execution returned AGY_V2_BRIDGE_EXECUTION_OK and confirmed injected MCP capabilities

Model(s): GPT-5.6 Sol, GPT-5.6 Luna, Gemini 3.8 Flash Medium
Harness: T3 Code Codex harness and T3 Code Orchestrator V2

[macroscopeapp]

Approvability

Verdict: Approved at 95dd67d

Macroscope's review found this PR approvable — This is a narrowly scoped ACP MCP bridge startup fix that preserves existing script-based launches and changes only the self-contained runtime argument vector. The production change is small, isolated, and covered by a focused regression test.

^{You can add or adjust custom eligibility rules. Learn more.}

[pekth]

Verification update

The failure is in T3 Code's ACP bridge launch arguments. When the server entrypoint resolves to process.execPath, the adapter passes that executable a second time before acp-mcp-bridge. The self-contained runtime then rejects the invocation before MCP initialization. The regression exercised this adapter path and failed before the fix; omitting the duplicate entrypoint made it pass. Script-based launches keep their existing arguments.

The existing patch was locally rebased onto b488c57f3f9f1688e31c53daee99e29dd1d0baa2 as 9116c10deb6ec55bbdbdb47427b180499a76bafa. git range-diff reports the patch unchanged. Verification on that local revision passed:

• All 117 focused adapter and MCP bridge tests.
• Targeted formatting and lint, with one existing lint warning outside the added test.
• Server typecheck and vp run --filter t3 build:bundle.

The previously recorded isolated Antigravity execution returned AGY_V2_BRIDGE_EXECUTION_OK. It predates this rebase and was not rerun on the rebased revision.

The rebase is not published yet: this PR still points to 95dd67d7fe6faa9e606e9d8f2c93f30e999d148c and GitHub reports base conflicts. The delivery restriction is local tooling, separate from this bug. This PR remains limited to the adapter fix and its regression test.

Verification update by GPT-6 in the T3 Code Codex harness; the tests and build above were run by GPT-5.6 Sol in the preceding turn.

[juliusmarminge]

Rebased onto v2 and pushed one follow-up commit on top of yours (ef80d2e):

• The self-contained check now asks node:sea (isSea()) instead of comparing process.execPath with argv[1]. Node only repeats the binary at argv[1] as a fix-up for the missing script path, so path equality was an accident rather than the signal, and the repo already uses node:sea for this elsewhere (HostProcessIsExecutable).
• T3_ACP_MCP_ENTRYPOINT is no longer set when running as the executable, and the terminal-fallback instruction in T3OrchestrationInstructions.ts now expands the entrypoint only when present (${T3_ACP_MCP_ENTRYPOINT:+"$T3_ACP_MCP_ENTRYPOINT"}), so acp-mcp-call also works under the packaged binary. That path had the same t3 t3 acp-mcp-call bug.
• Your test now mocks node:sea rather than mutating process.argv, and also asserts the env shape.

Verified locally: AcpAdapterV2.test.ts, T3OrchestrationInstructions.test.ts, AcpRuntimeModel.test.ts pass; vpr typecheck in apps/server is clean. Will merge once CI is green. Thanks for tracking this down.