Migrate TUI search panel + GTK search panel to quadraui (consolidate native widget + bespoke paint)

[JDonaghy]

Context

Vimcode's search panel is one of the last large bespoke paint surfaces in the codebase, with a particularly mismatched pattern across backends:

• TUI: src/tui_main/panels.rs::render_search_panel is ~600 lines of cell-by-cell paint, no quadraui delegation.
• GTK: uses native gtk4::Box widgets composed inline in src/gtk/mod.rs (search_panel_box) — not Cairo paint at all. Distinct architecture from vimcode's other GTK panels.

So the consolidation win here is bigger than a normal migration: TUI gets unified with GTK on a declarative primitive; GTK loses its bespoke native-widget approach in exchange for the same primitive. Both backends stop being one-off implementations.

Now blocked on

• JDonaghy/quadraui#7 — New SearchPanel primitive (or validated MSV+TreeView composition for the search pattern).

The recommended approach in #7 is to spike whether MultiSectionView + TreeView (with Decoration::Header for file headers) covers the pattern. If yes, no new primitive — vimcode adopts an MSV-shaped consumer pattern. If no, a dedicated SearchPanel primitive ships first.

Adoption gate

Before this migration ships:

1. ⏳ Resolution of JDonaghy/quadraui#7 — either MSV-pattern documented OR new primitive shipped with TUI + GTK rasterisers.
2. ⏳ Round-trip harnesses passing for whichever primitive(s) the resolved approach uses.
3. ⏳ Consumer pattern validated — part of Release v0.3.4 — bug fixes #7's spike.

Scope when unblocked

Two possible shapes depending on #7's outcome:

If MSV-pattern wins:

• Adapter: render::search_panel_to_multi_section_view(search) produces an MSV with aux: Input (search field), aux: Toolbar (filter toggles), one Tree body grouped by file.
• Replace render_search_panel (TUI) with the MSV adapter call.
• Replace search_panel_box native-widget composition (GTK) with a DrawingArea consuming the same MSV. Note: this is a bigger GTK-side change than other migrations because it switches from native widgets to Cairo paint.

If new SearchPanel primitive:

• Adapter calls quadraui::tui::draw_search_panel / quadraui::gtk::draw_search_panel.
• Same GTK-side architecture switch.

Where to look

• src/tui_main/panels.rs::render_search_panel — bespoke TUI paint
• src/gtk/mod.rs search_panel_box setup + key/click handlers — native-widget composition to replace
• src/render.rs search panel data shape

Risk callouts

• GTK loses native input-focus visuals. GTK's native Entry widget has system-styled focus rings, IME support, etc. A Cairo-painted equivalent will need to handle these explicitly. Worth confirming the trade-off before starting.
• Search panel is one of the more complex panels (multi-row results, file headers, regex toggles, async results streaming). Migration is larger than menu bar.

Out of scope

• Search engine / regex backend changes.
• Win-GUI search panel.

[JDonaghy]

Updated prereqs (2026-05-04)

quadraui#7 (MSV+TreeView spike) is resolved — composition validated, no new primitive needed.

New blocker: quadraui#52 — Form needs ToggleGroup + ButtonRow field kinds for the search panel chrome (toggle buttons + action buttons on horizontal rows). Without these, the form chrome would be 8 rows tall instead of 4.

Migration plan once unblocked:

• Section 0: body=Form (query TextInput, replace TextInput, toggles ToggleGroup, buttons ButtonRow, status ReadOnly)
• Section 1: body=Tree (file-grouped results with Decoration::Header for file names)
• Both backends: single draw_multi_section_view() call, zero bespoke paint