feat: ask which agents to use on first launch

[omartelo]

lich opened its first session on Claude Code because Claude was the only harness its author ran. A machine with Codex and nothing else met a first session that died on claude: command not found, and the three other harnesses sat off in a Settings screen nobody had been pointed at.

What changes

Detection runs before anything is shown, and the first launch opens on the providers it found — what is actually installed, a switch each, and the pick of which one new sessions spawn. The first one found arrives on, so the common case is one click on Continue. The body is <ProvidersSettings installedOnly />, the Settings › Providers panel verbatim, so the screen a user meets on day one is the one to come back to.

The dialog cannot leave without writing the choice it exists to collect: no close button, open pinned true, onOpenChange swallowing Escape and the backdrop.

Also adds oh-my-pi to the registry — the omp binary, a Pi fork — wearing lobehub's Pi mark. Upstream draws that mark as two paths under fill-rule="evenodd"; concatenated they render identically under the default nonzero rule, so ProviderIcon keeps its single-path shape.

Three decisions worth reviewing

The gate is provider.default being empty. It is the one setting only a deliberate choice writes, so empty means "never chose" — no new flag, no localStorage, and it lives in the DB beside the choice it guards. Consequence: an existing install that never opened Settings › Providers sees the dialog once on upgrade. That reads as correct here — the default is changing and they should see it — but it is a popup in front of people who did not ask for one. Seeding provider.default = "claude" for existing workspaces would make it truly first-run-only.

Continue writes an explicit flag for every provider, including the ones the filter hid. readEnabled returns true for Claude even when it is absent from PATH, so without that write a Codex-only machine would keep Claude out of the visible list and still be offered it in New Session.

Only installed harnesses are listed. The question is which of your agents to use, not a catalogue of what lich supports — "Not found on PATH" rows are noise there and the useful state in Settings. With nothing installed the shape inverts: no switches at all, just the names lich looks for, because five dead toggles under a "Default provider" nobody can honour contradict the title above them.

Test plan

Backend and frontend suites cover the pure logic — decideProviderSetup has the wait / skip / preselect / nothing-installed cases. The frontend gate runs in node with no jsdom, so it cannot catch a render crash: the first build of this gate passed all 653 tests and painted a blank window (React #185 — setProviderEnabled emits synchronously, useSyncExternalStore re-entered the effect before any setState landed, and the state guard recursed; the latch had to be a ref).

So the dialog was driven headless over CDP against a fresh config directory and a controlled PATH:

• Three harnesses on PATH — lists the three, first one ticked, both themes
• Codex only — Codex is the list, the tick and the default; DB reads provider.claude.enabled|0, provider.codex.enabled|1, provider.default|codex
• Nothing on PATH — names what lich looks for, no switches, Continue still lets the user in
• Continue closes the dialog and reveals the app
• omp spawns under lich (bun .../omp as a child) and paints a real TUI in the PTY — alternate screen, SGR mouse tracking
• gofmt, go vet, go test ./..., tsc, biome check, vitest, vite build

Not touched: any OS seam, so no ci:os.

Known gap

omp installed via bun install -g lands in ~/.cache/.bun/bin, which is not on PATH by default — lich will report it as "Not found on PATH" until that directory is added. That is where bun puts global binaries, not something lich can resolve.