UX: Show initialization progress and hide cursor until backend ready

[randomm]

Problem

The Setting up environment... spinner completes in ~2 seconds, showing ✓ Ready, but the backend is NOT actually ready. When user types /start immediately after, the system hangs for 5-10 more seconds.

Root Cause (Confirmed by Research)

bootstrap() only loads config, plugins, and file watchers (~2s). The HEAVY initialization is lazy:

1. Provider.state() (~1-3s) — fetches model configs, checks auth keys for ~30 providers
2. MCP.state() (~2-5s) — connects to each MCP server (stdio/HTTP transport + listTools())
3. Agent.state() (~0.2s) — loads agent definitions

These trigger on the FIRST command (resolveTools() in session/tools.ts), NOT during bootstrap.

Fix

Force eager initialization INSIDE the bootstrap callback, before showing ✓ Ready:

await bootstrap(process.cwd(), async () => {
  // Force eager init of heavy subsystems
  await Promise.all([
    Provider.list(),    // Forces Provider.state() 
    MCP.tools(),        // Forces MCP.state() — connects all servers
  ])
  // Now we're actually ready
  setup.stop(true)
  write('✓ Ready')
})

This moves the 5-10s delay INTO the spinner, so users see ⠋ Setting up environment... for the full duration and ✓ Ready means it's truly ready.

Key Files

• packages/opencode/src/cli/lite/index.ts — add eager init calls inside bootstrap callback
• packages/opencode/src/provider/provider.ts — Provider.list() forces state init
• packages/opencode/src/mcp/index.ts — MCP.tools() forces connection

Related

• UX: Redraw screen on oclite boot — cursor at bottom #85 (clear screen on boot)
• [Architecture] oclite: Live Block rendering with log-update for tools, tasks, and todos #82 (Live Block)

[randomm]

Additional QA Observation (Jan 27)

After pressing Enter on /start, there's a visible gap where the cursor sits on a blank line with no feedback before the spinner appears. This is likely caused by block.reset() (which calls logUpdate.done()) running before Spinner.start() in streamResponse(), or the spinner's first frame not rendering until the next tick.

Screenshots from commit 85c396e show:

• Screenshot 21:05:45: cursor on blank line, no spinner
• Screenshot 21:06:03: spinner visible at ⠇ Thinking · 4s

The spinner IS working, but there may be a ~1s delay before the first frame renders. This could be the block.reset() interfering, or just the event loop not ticking the spinner interval immediately.

Related to Live Block integration (#82).

[randomm]

Fixed in 1923c5e — MCP.clients() added to eager init, spinner covers full 5-12s delay