perf(tui): Ctrl+P file picker runs a synchronous `git status` subprocess + 20k-file walk on the event loop

[Hmbown]

Problem

Opening the Ctrl+P /files picker blocks the event loop on a git status subprocess plus a full synchronous workspace walk before the picker can even paint.

Evidence

• crates/tui/src/tui/ui.rs:3936-3943 — the key handler calls file_picker_relevance::open_file_picker(app) inline in the async event loop.
• crates/tui/src/tui/file_picker_relevance.rs:77-98 — modified_workspace_paths spawns git -C <ws> status --short --untracked-files=normal and blocks on .output().
• crates/tui/src/tui/file_picker.rs:441-468 (+ :472-491, MAX_CANDIDATES = 20_000 at :36) — collect_candidates synchronously walks the workspace with WalkBuilder.
• No spawn_blocking anywhere in the chain — unlike the equivalent file-tree (perf(tui): file-tree expand does a synchronous recursive read_dir on the UI thread #3900) and @mention (perf(tui): path-like @mention completion re-walks the filesystem on every keystroke #3899) paths fixed in PR perf(tui): fix the five render/input hot paths (#3896–#3900) #3902.

Impact

On large repos, cold page cache, or network filesystems, git status alone can take hundreds of ms to seconds; the walk adds more. The whole TUI freezes — no redraws, no input — between pressing Ctrl+P and the picker appearing. Same failure mode #3899/#3900 fixed for adjacent features.

Proposed approach

Mirror the #3900 pattern: push the picker view immediately in a "Scanning workspace…" loading state, run build_relevance (git status) and collect_candidates on spawn_blocking_supervised, and deliver results through a shared cell the loop drains (like poll_mention_completion).

Acceptance criteria

• Ctrl+P paints the (loading) picker within one frame regardless of repo size.
• Results populate asynchronously; picker filtering behavior unchanged (existing file_picker.rs tests pass).