refactor(web): the command palette's thread items come from their own hook#22687

CommandPalette.tsx is ~3,400 lines: one 2,600-line dialog component builds every item, runs every add-project flow, and renders the results. Layer 2 of a stack that splits it into focused files so each piece reads on its own and the React Compiler caches each piece on its own inputs.

Moves thread items into useCommandPaletteThreadItems in CommandPaletteThreadItems.tsx. It owns the thread search, the provider entry map and the thread row content. The environment, project and sorted-group lookup hooks move to CommandPaletteLookups.ts so both files can share them.

This is the layer with the render win. In the dialog, the compiler cached the thread items in a scope that typing invalidated, so every keystroke rebuilt them and re-rendered the visible thread rows. In the hook, they depend only on the deferred search query. ThreadCommandSubtitle, ThreadRowLeadingStatus, ThreadSearchPullRequestNumber and ThreadRowTrailingStatus drop from 80 renders each to 0.

Measured with the fiber render counter, same browser session and seeded dev DB, swapping only the palette files between this layer and the one below it. Behavior is unchanged.

Tests: vp test run src/reactCompilerCoverage.test.ts -t CommandPalette (0 bailouts, new files included), vp test run src/components/CommandPalette.logic.test.ts, tsc --noEmit for apps/web, vp lint on changed files.

🤖 Generated with Claude Code