TUI blocks its first content on a 4.5MB provider payload; render the shell and populate async

Problem

opencode paints a frame quickly and then sits on a loading screen. On the latest published build (1.18.15, Linux, healthy network) the first frame appears at about 0.6s, and the actual UI, model list included, at about 3s. On current dev run from source the same pattern shows: frame at 1.9s, content at 4.3s.

I measured what the TUI waits on. The worker answers nothing until the instance bootstraps, and the TUI blocks its first content paint on the bootstrap calls. Per-call, from a dev run with the worker instrumented:

/provider alone is a third of the wait, and the whole response is the models catalog: about 4.6MB of provider and model definitions serialized over the wire on first load. That payload is the bottleneck now. The network problems that used to cause 10s+ stalls are already fixed in dev (filesystem-only Npm.install, models.dev with a 10s timeout, bundled snapshot, and TTL cache), but the size and the blocking remain.

Proposed direction

1. Render the shell first and populate content as data arrives, the way #39821 tried it. That PR was closed unmerged and predates the current packages/opencode layout, but the direction was right.
2. Stop shipping the full models catalog to the TUI on first load. The bundled snapshot already exists server-side; serve the picker from it or embed it client-side and refresh in the background, instead of a 4.6MB HTTP response gating the first paint.
3. Put timeouts on the remaining first-load calls (config.get, config.providers, agent, command). Log a warning, keep going with partial data, don't block content on them.

Related: #36798 (lazy CLI loading, open), #30453 (merged, startup time down 38%), #24868 (closed, static import tree).

For validation I'd run OPENCODE_SHOW_TTFD=1 (from #30453) plus a launch with the network blocked. Target: first frame under a second, and content that doesn't care about the models payload arriving late.