config: normalization diagnostic 'skipped malformed recognized value' doesn't name the offending field — bad package id silently drops whole provider #50756

Summary

The config normalization diagnostic skipped malformed recognized value reports only the provider root path, not the offending field. A single bad package id silently drops the entire provider and every model under it from the catalog, and the log gives no hint of which value was malformed.

Environment

• opencode version: 2.0.12 (CLI); desktop app 1.18.31
• OS: Linux 7.1.11-arch1-1-znver3 (Garuda/Arch), x64
• Terminal: xterm
• Shell: /bin/bash
• Install/channel: latest (desktop app bundle)
• Active plugins: @tarquinen/opencode-dcp, lowfat, sinkhole-guard, smartsnip-fork, opencode-auto-resume, opencode-handoff, opencode-token-optimizer, openslimedit

Reproduction

1. Define a provider in opencode.json(c) with the V2 key shape but a legacy V1 package id:

{
  "providers": {
    "llama-server": {
      "name": "Local LLama-Server",
      "package": "@ai-sdk/openai-compatible",
      "settings": { "baseURL": "http://localhost:11436/v1" },
      "models": {
        "coder": {
          "name": "coder",
          "capabilities": { "tools": true, "input": ["text"], "output": ["text"] },
          "limit": { "context": 131072, "output": 8192, "input": 131072 }
        }
      }
    }
  }
}

2. Reload or start the server.
3. The log emits only:

WARN configuration normalization diagnostic source=$HOME/.config/opencode/opencode.jsonc path=$.providers.llama-server kind=invalid action="skipped malformed recognized value"

4. The provider and all its models disappear from /models / the model selector — no further detail anywhere.

The block was otherwise valid: settings, capabilities, and limit were all accepted shapes. Only the package value was wrong (@ai-sdk/openai-compatible is a V1 id; V2 requires @opencode/ai/providers/openai-compatible).

Expected Behavior

• The diagnostic should identify the specific offending value or sub-path (e.g. $.providers.llama-server.package = "@ai-sdk/openai-compatible" is not a recognized value), and/or
• emit a targeted migration hint for known legacy values — npm→package and package ids like @ai-sdk/openai-compatible → @opencode/ai/providers/openai-compatible — since legacy/V1 configs are documented as remaining compatible and this rejection is exactly the migration hazard that path should smooth over.

Actual Behavior

Only path=$.providers.llama-server kind=invalid with no per-field detail. The whole provider is skipped silently, so every model beneath it vanishes with no indication that a single string inside the block is the cause.

Additional Context

• Frequency: consistent, every load/reload while the bad value is present.
• Impact: silent model loss is expensive to diagnose. The repro above was the end result of a long session during which the diagnostic led maintainers (and the agent) down unrelated paths — including bisecting limit.context values (trying 131072 vs 98304) — because the message never pointed at the field that was actually malformed.
• Workaround: set package to @opencode/ai/providers/openai-compatible (or any accepted runtime id); provider loads immediately.
• Related recent change: V1→V2 key-shape normalization (provider→providers, npm→package, options→settings, tool_call→capabilities) is in this version; this issue sits directly on that migration seam.