Proposal: support native API-key adapters with model-specific OpenAI endpoints

[eclipse1228]

Problem

OpenSwarm native-loop adapters currently assume one OpenAI-style request protocol per adapter. Some API-key providers expose coding models through both Chat Completions and Responses endpoints, so a model can be valid for a provider but fail when routed through the adapter-wide endpoint.

Proposal

Add a small, explicit endpoint strategy to the native API-key adapter layer. An adapter would declare which curated or catalog-resolved models use Chat Completions and which use Responses. OpenSwarm would keep its own tool loop, read-only protections, exact egress allowlist, timeout behavior, and streaming normalization for both protocols.

This is intentionally not a change to the default provider or a request to permit arbitrary provider URLs.

Alternatives considered

1. Implement a separate loop for every provider/protocol combination. This duplicates tool-loop, retry, usage, and safety behavior.
2. Allow arbitrary user-configured base URLs. This weakens the current auditable egress boundary for requests that may include repository context.
3. Keep Chat Completions only. This excludes valid models that require the Responses API.

The proposed approach keeps provider endpoints explicit while sharing the existing native-loop safeguards.

Validation case

OpenCode Go is one concrete validation case: different available models use Chat Completions or Responses. The implementation would remain opt-in, use explicit provider configuration, identify the client with a stable User-Agent and session header, and document provider-specific data handling. No model would be enabled automatically.

Would maintainers be open to this direction before I prepare a focused implementation PR?