[ENHANCEMENT] Investigate temperature support in OpenCode Go Responses models #2006

Problem (one or two sentences)

Investigate whether any supported models in the OpenCode Go Responses API presently support the temperature parameter, and ensure the settings UI accurately reflects the capabilities of each model.

Context (who is affected and when)

The model settings UI displays the temperature control unless a model explicitly marks temperature as unsupported.

The streaming Responses implementation and non-streaming Responses implementation omit temperature, with inline comments acknowledging this.

The GPT-5.6 Luna model definition does not explicitly disable temperature. The same inconsistency may exist on other Responses model definitions.

This means users may be offered a setting that has no effect on their requests, or, if the model in fact does support temperature, Zoo Code is not forwarding this via the Responses api.

Desired behavior (conceptual, not technical)

The UI temperature controls should not be shown if they are not implemented. If the Opencode Go gateway does in fact support this feature for a model, then the feature should be implemented in Zoo Code.

This investigation may produce subtasks depending on what is discovered.

Constraints / preferences (optional)

Prefer to opt-in to temperature than to opt-out. This means the omitting of temperature in a configuration will not accidentally produce gateway errors from models that do not support this feature.

Request checklist

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

Zoo Code Task Links (optional)

• Triggered by code review of PR fix(opencode-go): add GPT-6 Luna support for Opencode Go provider #2003
• Blog post discussing GPT-6 400 errors from certain temperature + reasoning combinations

Acceptance criteria (optional)

Scenario 1: Temperature is unsupported

Given the supported Responses-type model is selected as the OpenCode Go Responses model

When the model's temperature support is verified against the live gateway

Then the model is explicitly marked as not supporting temperature if the API rejects the parameter

And the settings UI hides the temperature control for that model

And a code comment references this issue or authoritative provider documentation explaining the limitation

But the temperature control must not be displayed when the selected model cannot use the setting.

Scenario 2: Temperature support varies by reasoning effort

Given the supported Responses-type model is configured with different reasoning-effort settings

When authenticated requests are tested against the live gateway

Then temperature support is documented for each relevant configuration

And the model capability and UI behaviour accurately reflect the verified support

But unsupported configurations must not expose an ineffective temperature control.

Scenario 3: Temperature is supported

Given the OpenCode Go Responses API accepts temperature for a model

When the model is configured and a request is sent

Then temperature is handled consistently with the verified API behaviour

And the settings UI exposes the control only when the setting can be used

But the implementation must not silently discard a user-configured temperature value while presenting it as an effective setting.

Scenario 4: Regression coverage

Given the affected OpenCode Go model definitions and model fetcher

When the relevant automated tests are executed

Then the tests verify the model capability flags and their propagation through the model fetcher

And the tests protect the expected settings UI behaviour

But a model must not inadvertently regain an unsupported temperature control through changes to its definition or fetching logic.

Proposed approach (optional)

• Verify with authenticated requests whether the Go Responses API rejects temperature for all models currently routed via Responses api, including whether support depends on reasoning effort.
• If rejection is confirmed, explicitly mark temperature as unsupported for the affected models so the UI no longer offers an ineffective control.
• Add a short comment explaining why temperature is disabled, with a reference to the issue or provider documentation recording the verification.
• Add regression coverage for the capability flag and its propagation through the model fetcher.
• If rejection is partial, document the conditions that produce a failure and provide advice to how support for the partial feature could be implemented.

Trade-offs / risks (optional)

No response