Native LLM runtime hard-blocks Google/Gemini and other non-OpenAI providers

Description

The native LLM runtime at packages/opencode/src/session/llm/native-runtime.ts has a hardcoded provider allowlist that blocks Google, Amazon Bedrock, Azure, and OpenRouter from using the native LLM path, even though native-request.ts has working adapters for them.

// native-runtime.ts:55 — the gate
if (providerID !== "openai" && providerID !== "anthropic" && !providerID.startsWith("opencode"))
  return { type: "unsupported", reason: "..." }
if (npm !== "@ai-sdk/openai" && npm !== "@ai-sdk/openai-compatible" && npm !== "@ai-sdk/anthropic")
  return { type: "unsupported", reason: "..." }

// native-request.ts:165-177 — the adapter
if (model.api.npm === "@ai-sdk/openai") return OpenAI...
if (model.api.npm === "@ai-sdk/anthropic") return Anthropic...
if (model.api.npm === "@ai-sdk/google") return Google...     // works but gate blocks
if (model.api.npm === "@ai-sdk/amazon-bedrock") return AmazonBedrock...
if (model.api.npm === "@ai-sdk/azure") return Azure...
if (model.api.npm === "@openrouter/ai-sdk-provider") return OpenRouter...

Impact

Users who enable OPENCODE_EXPERIMENTAL_NATIVE_LLM=true cannot use Google/Gemini, Amazon Bedrock, Azure, or OpenRouter through the native path. The AI SDK fallback silently catches these, so the bug manifests as inconsistent retry/streaming behavior rather than a visible error.

Root cause

The allowlist in statusWithFetch() was written when only three providers had native adapters. As more adapters were added to native-request.ts, the gate was never updated. The two lists are duplicated and drift apart when providers are added.

Suggested fix

Replace hardcoded provider/npm checks with a SUPPORTED_NPM_PACKAGES set exported from native-request.ts. The gate derives truth from the same source as the adapter, so they stay in sync by construction.