{file:} apiKey sent as literal Bearer token on `opencode serve` v2 session path (401) — works in run/TUI

Description

Custom provider via @ai-sdk/openai-compatible with
options.apiKey: "{file:/tmp/demo.key}".

Through opencode run and the TUI, the file reference is resolved and
requests authenticate. Through opencode serve — the v2 /api/session/*
path the desktop app drives — the Authorization header contains the
literal string {file:/tmp/demo.key}, so the upstream OpenAI-compatible
server returns 401.

Repro (fully local, no secrets): run any loopback OpenAI-compatible stub
that logs the Authorization header and 401s on a wrong key, with:

{
  "model": "demo/test-model",
  "provider": {
    "demo": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1",
        "apiKey": "{file:/tmp/demo.key}"
      },
      "models": { "test-model": {} }
    }
  }
}

then drive one prompt via /api/session/{id}/prompt. The stub receives
Bearer {file:/tmp/demo.key}.

Reproduced identically on 1.18.11 and 1.18.16. Also observed on this
path: PUT /auth/{providerID} is ignored (literal still sent), and
removing options.apiKey sends no Authorization header at all —
while GET /config on the same running server shows the key correctly
resolved. Only the session-execution path keeps the literal.

Looks like the same class as #13219, fixed in #13226 for
OPENCODE_CONFIG_CONTENT (config-load path skipping {file:}
substitution) — possibly the same fix belongs on the serve path.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response