[Bug]: Nightly gets stuck on "waiting for provider status" when OpenCode returns model names with trailing whitespace

[adinschmidt]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Install the nightly desktop build from GitHub Releases.
2. Ensure OpenCode is enabled and connected to an upstream inventory that includes model display names with trailing whitespace.
3. Launch T3 Code and open the app.
4. Observe the app remain stuck at waiting for provider status....
5. Open the browser devtools for the desktop webview and inspect the console.

Expected behavior

T3 Code should load provider state normally even if an upstream provider returns malformed display names.

Actual behavior

The initial config snapshot fails frontend decoding, the WebSocket config subscription dies, and the UI remains stuck on waiting for provider status... forever.

Impact

Blocks work completely

Version or commit

Observed on v0.0.21-nightly.20260420.77. I traced the same code path in main at f6978db6.

Environment

macOS, desktop nightly binary from GitHub Releases, OpenCode enabled. During repro the bad inventory entries came through OpenCode under the kilo provider, including Baidu model names with trailing whitespace.

Logs or stack traces

WebSocket RPC subscription failed
Expected a string with no leading or trailing whitespace, got "Baidu: ERNIE 4.5 300B A47B " at [0]["config"]["providers"][2]["models"][36]["name"]

I also saw follow-on union decode messages such as:

Expected "keybindingsUpdated", got "snapshot"
Expected "providerStatuses", got "snapshot"
Expected "settingsUpdated", got "snapshot"

Relevant bad values observed in the OpenCode inventory included:

kilo/baidu/ernie-4.5-300b-a47b -> "Baidu: ERNIE 4.5 300B A47B "
kilo/baidu/ernie-4.5-vl-424b-a47b -> "Baidu: ERNIE 4.5 VL 424B A47B "

Workaround

Disable OpenCode in ~/.t3/userdata/settings.json:

{
  "providers": {
    "opencode": {
      "enabled": false
    }
  }
}

Root cause appears to be that OpenCodeProvider forwards upstream model.name / provider.name directly into ServerProviderModel, while the shared contract requires trimmed non-empty strings. Trimming those strings at the boundary fixes the repro.