config: compatibility.supportsStore silently dropped from opencode.jsonc #52617

Summary

Model-level compatibility.supportsStore set in opencode.jsonc is silently ignored: the openai-compatible chat protocol keeps injecting "store": false into every request body, which strict gateways reject. A sibling key in the same block (maxTokensField) is honored, so the file is parsed — only some compatibility keys take effect.

Environment

• opencode version: 2.0.21
• OS: Linux 7.0.0-34-generic (linux x64)
• Terminal: WarpTerminal, TERM=xterm-256color, COLORTERM=truecolor
• Shell: /bin/zsh
• Install/channel: latest
• Active plugins: opencode-models-discovery@latest, superpowers@git+https://github.com/obra/superpowers.git, local rtk.ts

Reproduction

1. Configure an openai-compatible provider pointing at a backend that rejects unknown body fields (e.g. a LiteLLM proxy routing Claude models to a Bedrock/azure_ai backend), with one model:

   "models": {
     "claude-sonnet-5-5": {
       "modelID": "claude-sonnet-5-5",
       "compatibility": { "supportsStore": false, "maxTokensField": "max_tokens" }
     }
   }

2. Send any prompt with that model (or capture the outgoing request body with a local probe endpoint).
3. Observe the request uses max_tokens (override honored) but still contains "store": false.

Expected Behavior

With compatibility.supportsStore: false, the store key should be omitted from the request body entirely.

Actual Behavior

"store": false is always sent unless the provider id/baseURL matches the built-in nonstandard-provider list. The gateway responds with litellm.UnsupportedParamsError: azure_ai does not support parameters: ['store'], making the model unusable. Requests without store succeed (verified directly against the gateway).

Additional Context

• Inspecting the v2.0.21 binary, the config-file compatibility schema accepts reasoningField, requireReasoning, maxTokensField, requireFinishReason, requireAssistantAfterTool, supportsPromptCacheKey — but not supportsStore (nor supportsStrictMode, etc.), while the runtime LanguageModelCompatibility schema includes them. So the key is dropped at config load, never reaching detectSupportsStore's ?? request.model.compatibility?.supportsStore fallback.
• Consistent across repeated runs; no failed to load plugin / config errors logged for the entry (it is silently skipped, matching the existing configuration normalization diagnostic ... action="skipped malformed recognized value" pattern for unknown keys).
• Workaround attempted: an http.request session-hook plugin stripping store (works in isolation against a probe endpoint) — blocked by a separate reload bug filed alongside this one.