[ENHANCEMENT] Support verified temperature capability for OpenCode Go Responses models #2055

Problem (one or two sentences)

The OpenCode Go Responses integration does not pass the Zoo Code temperature setting to Responses requests. The settings UI can therefore show a temperature control for a model/configuration where the gateway rejects the parameter, or hide a control where the gateway accepts it.

Investigative testing has shown that the Opencode Go gateway is capable of responding successfully for models that support temperature.

Context (who is affected and when)

Users of OpenCode Go Responses models are affected when they configure temperature in Advanced Settings. The affected route currently includes gpt-5.6-luna, gpt-6-luna, grok-4.6, muse-spark-1.2-contributor and muse-spark-1.3-contributor.

The current implementation omits temperature from both the streaming Responses request path in src/api/providers/opencode-go.ts and the non-streaming Responses request path in src/api/providers/opencode-go.ts. The model registry does not express all observed capability differences. For example, gpt-6-luna is marked as not supporting temperature, while the results-matrix.html found successful temperature requests for some model and reasoning-effort combinations.

The investigation of #2006 tested six OpenCode Go models, multiple reasoning efforts, omitted temperature, and temperatures 0, 0.5, 1, 1.5, and 2. The test points were coarse probes across the UI's 0–2 range. They were not intended to define the UI resolution, which is 0.01 in TemperatureControl.tsx.

The results show that capability is not uniform:

grok-4.6, grok-4.7, muse-spark-1.2-contributor, and muse-spark-1.3-contributor accepted the tested temperatures whenever the request completed, apart from transient failures.
gpt-5.6-luna and gpt-6-luna accepted all tested temperatures with reasoning effort none.
The same GPT models returned explicit HTTP 400 unsupported-parameter errors for most non-none reasoning combinations, but temperature 1 returned HTTP 200 in those combinations.
The contradictory GPT result means that a blanket enable or disable decision would be unsafe without a capability rule that reflects the verified model configuration.

Desired behavior (conceptual, not technical)

Users should see an effective temperature control only when the selected OpenCode Go model and reasoning configuration can use it.

When temperature is supported, the selected value should affect both streamed and non-streamed requests sent to the gateway. When temperature is unsupported, the control should be hidden and both request paths should omit the parameter. Changing the model or reasoning setting should not leave an ineffective temperature value active.

Constraints / preferences (optional)

• Prefer opt-in temperature support. An unverified configuration must omit temperature rather than risk a gateway error.
• Preserve the existing Zoo Code UI range and resolution: 0 to 2, in 0.01 increments, unless the provider contract requires a narrower range.
• Do not treat timeout, HTTP 500, or HTTP 502 results as proof that temperature is unsupported.
• Keep model capability metadata aligned with the request builder and settings UI.
• Preserve the omitted-temperature behavior when the user has not enabled a custom value.
• Use the existing local cachedState settings pattern so the control does not bind directly to live extension state.

Request checklist

• I searched the existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Zoo Code Task Links (optional)

Investigation issue: #2006
Investigation findings: results-matrix.html

Acceptance criteria (optional)

Scenario 1: Unsupported configuration

Given an OpenCode Go Responses model and reasoning configuration that does not support temperature

When the user selects that configuration

Then the temperature control is hidden

And both streaming and non-streaming Responses requests omit temperature

But a saved temperature value must not be sent to the gateway for that configuration.

Scenario 2: Supported configuration

Given an OpenCode Go Responses model and reasoning configuration that supports temperature

When the user enables custom temperature and sends a request

Then the selected temperature is included in both streaming and non-streaming Responses requests

And the value is preserved at the supported UI resolution

But the request must not silently discard the visible setting.

Scenario 3: Configuration changes

Given a user has configured a temperature value

When the user changes to a model or reasoning configuration with different temperature capability

Then the UI reflects the new capability

And the request behavior changes with it

But an unsupported configuration must not inherit an effective-looking temperature control.

Scenario 4: Capability metadata and regression coverage

Given the supported OpenCode Go model definitions and model-fetcher

When the relevant automated tests run

Then they verify capability metadata for each affected model/configuration

And they verify propagation into the settings state and request builder

And they verify both supported and unsupported UI states

But a missing or incomplete capability flag must not silently re-enable an unsupported control.

Proposed approach (optional)

1. Use the investigation matrix as the initial evidence set.
2. Confirm the contradictory GPT temperature-1 cells before encoding the final capability rule.
3. Represent temperature support as explicit model/configuration capability metadata, or as a provider-specific resolver if support depends on reasoning effort.
4. Use that capability decision in the Settings View, streamResponsesMessage, and the non-streaming completePrompt Responses path.
5. Add focused tests for model definitions, model fetching, UI visibility, and temperature omission/forwarding on both request paths.
6. Add a short source comment linking this issue and the provider evidence.

Trade-offs / risks (optional)

The gateway capability may change without notice, so live observations alone cannot guarantee permanent support. A conservative opt-in rule reduces gateway errors but may hide temperature for a newly supported configuration until its capability is verified. A model-level flag is simpler, but it may be too broad if support depends on reasoning effort. A configuration-aware rule is more accurate, but it requires capability data to remain available to both the UI and request layer.

The implementation should not infer capability from transient request failures, and it should not expose a setting that the request path intentionally discards.