feat(opencode-go): expose Muse Spark reasoning effort aliases

[excessivechaos]

Summary

• advertise Muse Spark 1.2 Contributor in the OpenCode Go registry with its 1M context and multimodal capabilities
• expose minimal/low/medium/high/xhigh aliases in the Combo Builder
• resolve suffixed model IDs to the base model plus reasoning_effort at request time

Verification

• focused OpenCode Go effort and catalog tests passed
• composite validation includes the dispatcher regression suite from fix(network): bound direct-path response-start timeout and retry on fresh socket (#10214) #10528

The CommandCode effort work is intentionally separate.

[adevwithpurpose]

Hi @excessivechaos @diegosouzapw,

Testing with muse-spark-1.2-contributor-free on the opencode (noauth/free) provider revealed an issue on multi-turn conversations after this merge:

When a conversation history grows or has effort configured, the free contributor endpoint returns an empty assistant completion (finish_reason: null, 0 text content, 0 tool calls):

[400]: {"id":"chatcmpl_...","object":"chat.completion","model":"muse-spark-1.2-contributor-free","choices":[{"index":0,"message":{"role":"assistant"},"finish_reason":null}]}

Observations:

• opencode-go/index.ts advertises 1048576 (1M) context for muse-spark-1.2-contributor.
• However, on the free tier (opencode:muse-spark-1.2-contributor-free), the upstream endpoint appears to enforce a ~128k context ceiling and cuts off without content when that limit is approached.
• It may be helpful to differentiate the context window between paid opencode-go (1M) and free opencode (~128k) and guard against dropping empty chunks when finish_reason: null is received.

[excessivechaos]

Thanks for the detailed report @adevwithpurpose — we investigated this on a fresh deployment of the merged code and confirmed the upstream itself is rejecting the model, independent of this PR's changes.

Direct upstream reproduction (no OmniRoute in the path)

POST https://opencode.ai/zen/v1/chat/completions with model=muse-spark-1.2-contributor-free:

• Single-turn, 1 user message, no reasoning_effort, non-stream:

  {"id":"chatcmpl_...","object":"chat.completion","model":"muse-spark-1.2-contributor-free","choices":[{"index":0,"message":{"role":"assistant"},"finish_reason":null}]}

  → HTTP 400
• Same request with stream:true → identical 400
• Same request with reasoning_effort:low → identical 400
• The model IS present in the live catalog: GET https://opencode.ai/zen/v1/models returns both muse-spark-1.2 and muse-spark-1.2-contributor-free

So the empty-assistant 400 reproduces with the most minimal request possible — it is not gated on conversation history size, multi-turn, or effort configuration. This looks like an upstream serving defect (model listed in the catalog but the chat endpoint rejects it).

This PR does not change the free-variant request path

• parseEffortLevel('muse-spark-1.2-contributor-free') → null (the -free suffix is not an effort tier, so no model rewrite and no reasoning_effort injection).
• isThinkingMessageModel('muse-spark-1.2-contributor-free') → false (muse is not in the thinking/reasoning_content replay family).
• The PR's registry change (opencode-go, 1M context, effort aliases) only affects the paid opencode-go tier. The free opencode/opencode-zen path uses the same base URL and the synced catalog entry that existed before the merge.

Agreed follow-up (separate from the 400)

Your point about context-window differentiation is valid and worth a separate fix: the free tier should advertise its ~128k ceiling for this model rather than inheriting the paid 1M context, and the empty-finish_reason:null response deserves a guard so it surfaces as a clean error instead of an opaque passthrough. Both are independent of the upstream 400 and can be tracked separately.

Happy to open a follow-up PR for the context-window/empty-response handling if that's wanted.