fix(runtime): propagate OpenCode Go session identity

[Totoro-qaq]

Summary

OpenCode Go requires every inference request to carry an x-opencode-session header with a stable conversation identity. Maka omitted the header from both normal model requests and direct Connection Test probes, which may cause those requests to be rejected by the provider.

This change adds the header at the shared request-customization boundary and propagates the existing Maka Session identity through:

• normal model requests and tool-loop steps;
• history compaction;
• session-scoped auxiliary calls such as title, recap, memory extraction, and goal evaluation;
• OpenAI Chat, Anthropic Messages, and Responses wires.

Operations without a Session use one identity per operation: Connection Test generates one UUID and reuses it across its internal attempts, while Daily Review generates one call identity and reuses it for provider retries.

The header is restricted to opencode-go. An explicitly configured x-opencode-session header takes precedence case-insensitively, and no user content or credential material is included in the generated value.

Fixes #4663

Related upstream report:
vercel/ai#20271

Verification

• Confirmed RED before the fix:
  • ModelAdapter did not forward its Session identity.
  • OpenCode Go Chat, Messages, Responses, and Connection Test requests omitted x-opencode-session.
  • Daily Review used the global constant daily-review instead of a unique per-operation identity.
• Focused OpenCode Go regression tests: 7 passed, 0 failed.
• Runtime Host model-composition suite: 28 passed, 0 failed.
• @maka/runtime full suite: 3,189 passed, 13 skipped, 0 failed.
• Root build:test completed successfully after rebasing onto current main.
• Full-repository lint and format checks, git diff --check, and the ASF license-header audit passed.
• DeepSeek Harness reviewed the patch with deepseek-v4-pro at max reasoning. Its shared Daily Review identity finding was reproduced and fixed with a regression test.

A full Runtime Host package run also exposed an unrelated timing failure in owned Host exits promptly after its first connection closes: the Host did not settle within its fixed 500 ms local deadline. The affected model-composition suite passes in full after a clean root build.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex reproduced the missing-header paths, implemented the fix, added regression coverage, and ran the local verification. DeepSeek Harness performed an independent read-only review that identified the Daily Review identity collision fixed in the final patch. The commit contains a Generated-by: OpenAI Codex trailer.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Traced the production path and the change lands on the existing seams: ModelAdapterInput.sessionId and transportContextId already existed, and the four non-test getAIModel call sites (main, history compaction, every auxiliary call) are all covered, so identity still has exactly one source. Tests exercise the real owners (testConnection, getAIModel, ModelAdapter, Host composition) rather than a bypassed fixture. No P0/P1/P2 from me.

One thing I checked and want to record so nobody re-derives it: hasRequestCustomization is now true for every OpenCode Go request, and the openai / openai-codex arms of getAIModel use that flag to skip openAiResponsesTransportState.wrapFetch. That is not a regression here because opencode-go declares runtimeAdapter.kind: 'openai-compatible', and that arm does not read the flag. It would become one if the provider ever moved to the native OpenAI adapter.

P3: the header is scoped to opencode-go only. opencode and opencode-free share the OpenCode catalog and model ids. Could you say what the upstream evidence is that the Zen and Free endpoints do not need x-opencode-session? I could not verify that either way.

CI has not run at this head: the CI workflow run is sitting at action_required, so only the label job reports. Worth getting a green run before merge, especially with the upstream 2026-09-05 date in the issue.

[Astro-Han]

Approving at 2c33a62. The remaining notes in my previous review are P3 and do not block. CI has not run on this head yet (workflow approval pending), so merge waits on a green run.

[Totoro-qaq]

Thanks for checking this.

The scope comes directly from vercel/ai#20271. The reporter identifies the
affected service as the OpenCode Go managed-inference API, and the AI SDK
maintainer explicitly describes x-opencode-session as an OpenCode Go-specific
header.

The maintainer also recommends persisting the application conversation ID for
multi-turn conversations and generating one UUID for one-off calls, which
matches the Session / Connection Test / Daily Review split in this PR.

I found no upstream requirement for the separate Zen or Free endpoints, so I
kept this fix scoped to opencode-go rather than sending a correlation header
to providers not covered by the reported contract.