#91 fix(tui): actually run the live catalog refresh when the model picker opens

[Anonymous]

Originally created by: sosidudku1

Problem

PR [#67] shipped full live catalogs for OpenRouter and aimlapi, but the TUI never actually started the fetch. The refresh trigger was dispatched as a reducer action from the keymap layer, and the reducer never reaches the event bus that ProvidersOrchestrator subscribes to. The request died there, so the wizard pickers kept rendering the short static lists (18 OpenRouter, 13 aimlapi) instead of the full live catalogs.

Change

• The wizard's curated pick_chat_model step now owns its refresh: the static list renders immediately, the live fetch starts the moment the step opens with an "updating model list from API" note, and the step re-renders onto the live list when the fetch lands. Rows still come from listChatModelsForKind, so key bindings and the render layer read the same list. A failed fetch quietly leaves the static list on screen.
• onProvidersTabRefresh (TUI start and providers/LLM tab activation) also calls the new prefetchCloudCatalogs, with a warm-cache guard so repeats within the 1h TTL cost nothing.
• The catalog fetchers dedupe concurrent refreshes into a single request.
• Removed the dead providers_catalog_refresh_requested action and its no-op dispatch sites.

Testing

6 new tests, all with mocked fetch: cold-open refresh swaps the static list for the live one and clears the loading note; a failed refresh stays on the static list without crashing; prefetchCloudCatalogs fetches both catalogs when cold, skips the network while warm, retries after failures; concurrent refreshes share one in-flight request. tsc clean; targeted suites 128 tests green; full run shows no new failures beyond the known floating set.

[Anonymous]

Ticket changed by: Ooooze

• status: open --> closed