feat(server): add native OpenCode 2 support on orchestrator v2

[Hoodgail]

Problem

Released OpenCode 2 uses the opencode executable but changed its startup banner, authentication and HTTP API. The current integration waits for the V1 banner and then calls V1 SDK endpoints, causing the timeout and empty catalog reported in #11790.

Changes

Add a native @opencode/client@2.0.10 adapter at the new orchestrator boundary while preserving the V1 adapter and existing provider identity/settings. Local sessions share the provider instance's owned server; external servers retain their ownership. Inventory, chat and generation use the selected API generation.

The native path enforces permissions on the server session, reconciles messages and pending requests after stream reconnection, preserves whitespace, follows pagination cursors correctly, restores the selected agent after plan mode, and cancels prompt-hook questions before waiting for Stop admission. Background generation uses a workspace-scoped temporary session with server-enforced tool denial. Generated passwords are redacted from startup failures; only explicitly configured credentials are used for external servers.

Draft scope

Stacked on #2829; base is t3code/codex-turn-mapping. Keep this draft pending the orchestrator rewrite and maintainer agreement on the remaining provider scope, per the closing comments on #8207/#12084/#12284.

This is an initial native integration, not full feature parity:

• Provider-native subagents are disabled and T3's per-thread MCP injection remains unimplemented.
• Active steering uses T3's interrupt/restart capability instead of concurrent native prompts.
• Conditional, hidden and external forms are explicitly declined. Ordinary typed questions are supported.
• Only /compact is advertised from the native command path.
• OpenCode 2.0.10 is the minimum supported native version. Earlier OpenCode 2 versions receive an upgrade error.

Validation

Local macOS validation against the pinned rewrite base:

• 153 focused tests: OpenCode V1 regressions, native-client contracts and adapter lifecycle tests.
• Opt-in released-CLI tests with OpenCode 2.0.10 and a local mock model: authenticated inventory, policy evaluation, pagination, forks/workspace moves, a complete native T3 adapter turn, tool-free text generation, and image delivery.
• Server typecheck; lint and formatting for changed files.
• Production server bundle and bundled CLI --help smoke test.
• Server-scoped Knip check for files, dependencies and exports.
• Frozen dependency install and generation of MIT notices for all three new OpenCode packages.

Run the live contract suite with:

OPENCODE_TEST_BINARY=/absolute/path/to/opencode vp test run apps/server/src/provider/OpenCode2.live.test.ts

The CLI tests use isolated state and a local mock model. Cross-platform execution and the upstream CI/review gates remain required before promotion from draft. No frontend source changes.

At publication, GitHub marked the upstream CI run action_required before any jobs started: https://github.com/pingdotgg/t3code/actions/runs/35473766485. Maintainer authorization is needed for those fork-PR workflows; the local checks above are complete.

Model: GPT 6 Astra (Strata). Harness: OpenCode.

[juliusmarminge]

Rebased this PR onto the current t3code/codex-turn-mapping at 4a4c22b29c. Your single commit applied cleanly; no conflicts. The PR stays a draft.

One fix on top (2373e79f16)

• In OpenCodeDriver.ts, the API-generation probe (server.version.startsWith("2.")) was an unmemoized effect, so every adapter call (getCapabilities, planSelectionTransition, openSession) and every resolveMaintenance re-ran connectExternal (an extra server.info round-trip, or a legacy health check) against the external server. The generation is fixed for the life of a driver instance, since settings changes rebuild the driver, so the probe result is now stored in a Ref after the first success and reused. A failed probe is not cached, so a server that is temporarily unreachable can still be picked up on the next call. I kept it on the driver rather than the server handle, since the handle is per-connection and this is per-instance state.

Deliberately left alone

• resolveMaintenance still uses Effect.orElseSucceed(() => true) when the probe fails. ServerProviderShape["resolveMaintenance"] is typed as Effect<ProviderMaintenanceCapabilities> with no error channel, and makeManagedServerProvider and every other driver rely on that, so surfacing the failure would widen the contract across the provider layer. Worth a follow-up if you want it, but out of scope for a touch-up. Note the defaulting to "native" means a legacy server behind a flaky connection can briefly show manual-only maintenance capabilities.

Verified

• vp test run in apps/server for OpenCode2Adapter.test.ts, OpenCode2Client.test.ts, OpenCodeServerOwner.test.ts, opencodeRuntime.environment.test.ts, Layers/OpenCodeProvider.test.ts, textGeneration/OpenCodeTextGeneration.test.ts: 65 passed. OpenCode2.live.test.ts was skipped (needs OPENCODE_TEST_BINARY).
• vpr typecheck in apps/server: clean.

Rebased and touched up by a maintainer's agent; a human will re-review.