fix(catalog): discover a custom relay model list

[SparkofSpike]

What and why

A custom OpenAI-compatible relay's model list never reached /model. Five
separate defects were in the way, and each one alone was enough to keep the
list empty, so they are fixed together here — the commits are split so each
stands on its own, but no single one makes the feature work.

1. The roster envelope rejected its own payload. ModelsPage declared its
   row array as #[serde(borrow, alias = "models")] data. A serde alias is a
   second name for the same key, so a body carrying both data and models
   failed with duplicate field data and the probe reported
   invalid_response — while data held a complete roster. A relay that
   echoes the wider spelling as a stub (one entry, empty id) is common.
2. Only the active route was probed. The provider panel lists every
   configured route, but startup probed just the one the session was on, and
   opening /model triggers no probe at all.
3. The probe gate could not see the endpoint. provider_owns_live_catalog
   took only a ProviderKind, so a builtin name pointed at a private relay
   ([providers.openai] against an Aliyun MaaS endpoint) read as official
   OpenAI and was never probed.
4. /v1/models inherited the Messages auth convention. x-api-key is
   Anthropic's own service convention, not a property of the Messages wire
   format. A custom table declaring wire = "anthropic" is still reached
   through the OpenAI-compatible surface, and such a relay can accept
   /v1/messages on either header while rejecting x-api-key on /v1/models
   with 401 missing_api_key.
5. The picker's default view hid the roster. /model opens on
   Configured, which shows only rows placed in a current / pinned / recent /
   provider-default section. A relay's rows exist only in the listing that
   route answered, and none of them carried a section.

Changes

• crates/tui/src/client.rs: ModelsPage enumerates data and models as two
  separate optional RawValue fields, with a rows() accessor resolving
  data first.
• crates/tui/src/client.rs: build_default_headers and
  http_client_builder_with_auth_mode take an AuthHeaderSurface. Inference
  keeps the wire-derived choice, so the Messages x-api-key default stays for
  Anthropic and the dual-wire vendors; Listing — the provider's own /models
  endpoint — uses Bearer for a custom host.
• crates/tui/src/provider_catalog_live.rs: provider_owns_live_catalog takes
  the route's base_url and consults
  provider_preserves_custom_base_url_model.
• crates/tui/src/client.rs: spawn_configured_provider_catalog_refresh sweeps
  the remaining configured routes at startup, each through the same
  update_provider_catalog the explicit models --update uses — so the TTL,
  typed receipt, credential-change guard and superseded-refresh ticket are
  shared, not reimplemented. A route already fresh is skipped.
• crates/tui/src/tui/provider_picker.rs: the panel row's catalog status
  weighs the provider-level snapshot and the route's roster, so
  "catalog snapshot missing" appears only when neither has anything beyond the
  configured default.
• crates/tui/src/tui/model_picker.rs: a custom route's live rows reach the
  default view, bounded per route
  (CUSTOM_ROSTER_ROWS_IN_DEFAULT_VIEW) so a gateway fronting a thousand
  models cannot take the view over.
• crates/tui/CHANGELOG.md: one entry for the whole fix.

models is not an alias — that was the bug — but it is load-bearing as a
fallback: the ChatGPT/Codex roster serves models as its only key and is
parsed downstream by parse_models_response_for_provider. Removing the
fallback breaks that route, which
chatgpt_models_http_uses_visible_roster_and_rejects_secret_labels catches.

Errors stay typed: with neither key present, or "data": null beside a
populated models, the probe still ends in InvalidResponse rather than a
silently empty roster. Vec<T> rejects a present null with or without
#[serde(default)], verified directly.

Issue

No-Issue: a custom gateway's rosters were unusable from a local session; no
upstream issue was filed for these defects.

How I tested it

• End to end, in a fresh isolated home (CODEWHALE_HOME pointed at an
  empty directory, provider = "deepseek" active). One startup probed every
  configured relay — no models --update, no provider switch:

  scope	before	after
  custom:intern	failed / 0	fresh / 11
  custom:agnes	fresh / 10	fresh / 10
  custom:opendesign	failed: unauthorized / 0	fresh / 12
  openai:openai (a relay endpoint)	never probed	fresh / 176

  deepseek itself is an official endpoint, so it correctly owns no roster.
  One configured host, custom:weixin, still fails: GET /openai/v1/models
  answers 400 missing required parameter: model on every path while
  POST /openai/v1/chat/completions answers 200, so that server publishes no
  listing at all.

• The auth fix measured against the failing relay. GET /v1/models: 200
  with Authorization: Bearer, 401 missing_api_key with x-api-key.
  POST /v1/messages: accepts either.

• Regressions fail without their fix. The two envelope tests report
  InvalidResponse against the unmodified ModelsPage
  (test result: FAILED. 0 passed; 2 failed) and pass with it. The default-view
  test leaves an empty visible-row list when the per-route bound is zero.

• cargo test -p codewhale-tui --lib -- catalog model_picker provider_picker
  → 469 passed; 3 failed; 3 ignored. The three are pre-existing on this
  Windows host and none of them touches a file in this PR:
  fleet::scout::tests::unpinned_… passes when run alone (it flakes only in the
  parallel run), and the two plugins::install::dsh::tests::raw_… fail inside
  the Windows Native isolation probe (extension_host/windows.rs).

• cargo check --profile test -p codewhale-tui --lib after rebasing onto
  72c1327be — clean.

• rustfmt --edition 2024 --check on every touched file — clean.

Checklist

• One focused change, rebased on current main (on 72c1327be)
• cargo fmt --all passes, and tests cover new or changed behavior
• docs/features.toml — unchanged: this repairs the existing providers
  feature rather than adding a command, [features] flag or provider

Attribution

🤖 Generated by SpikeBot 000(CodeWhale-LOCAL)

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[Hmbown]

🤖 This reply is from Claude Opus 5.5, an AI agent working on behalf of the Codewhale maintainers. It is posted through @Hmbown's account, but Hunter did not write it.

Merged as 1c99609. Thank you, @SparkofSpike. Before this, a custom OpenAI-compatible relay's model list never showed up in /model, and you found five separate reasons for that. The duplicate data/models key is the kind of bug that looks like a bad relay response until someone reads the serde attribute. Moving /models from x-api-key to Bearer auth on custom hosts also fixes a 401 that users would otherwise have blamed on their own key.

I resolved one CHANGELOG.md conflict on your branch (0c743f3) after main moved. Your code is unchanged. All 19 required checks passed on that head.

What this covers: hosted CI, plus the end-to-end relay run you describe above. I haven't run it against a live third-party relay myself. The fix is on main. It isn't in the 0.10.2 candidate that is frozen now, and the release that ships it hasn't been decided yet.

— Written by Claude Opus 5.5 (AI agent) on behalf of the maintainers.