Migrate menu dropdown from bespoke DrawingArea to quadraui::ContextMenu

[JDonaghy]

Summary

The menu bar labels were migrated to quadraui::MenuBar in #301, but the dropdown overlay is still a bespoke menu_dropdown_da DrawingArea with hand-rolled rendering and event routing. This blocks keyboard navigation (#308 item 1) because key events fight with GTK's redraw cycle.

The quadraui way

The quadraui/examples/common/menu_bar_app.rs example demonstrates the correct pattern:

• Dropdown rendered via backend.draw_context_menu(&ctx_menu, &layout) — the same ContextMenu primitive used for right-click menus
• Keyboard nav (arrows, Enter, Esc) handled in AppLogic::handle() — no per-backend key interception
• Hover-to-switch and dropdown item highlighting handled via ContextMenuLayout::hit_test
• Dropdown anchored below the menu bar item via ContextMenuPlacement::Below

What needs to change

1. Replace menu_dropdown_da (GTK bespoke DrawingArea) with a ContextMenu drawn during the main editor DA's paint pass
2. Push the dropdown onto the ModalStack (already done for right-click context menus)
3. Route keyboard events through the engine when menu_open_idx.is_some() — the engine handles Up/Down/Enter/Escape, both backends consume the result
4. Remove Msg::MenuHighlight, Msg::OpenMenu dropdown-DA logic, and the bespoke dropdown DA setup/paint/click code

What this unblocks

• Menu bar keyboard/hover dispatch gaps (GTK arrow keys, TUI Alt conflicts, TUI hover) #308 item 1 (GTK arrow key nav) — currently broken because bespoke DA redraws fight with key handler mutations
• Menu bar keyboard/hover dispatch gaps (GTK arrow keys, TUI Alt conflicts, TUI hover) #308 item 3 partially (TUI dropdown item hover) — ContextMenu hit_test gives this for free
• Consistent menu dropdown rendering across TUI + GTK

References

• quadraui/examples/common/menu_bar_app.rs — reference implementation
• Migrate TUI menu bar to quadraui::MenuBar primitive #301 — menu bar labels migration (parent)
• Menu bar keyboard/hover dispatch gaps (GTK arrow keys, TUI Alt conflicts, TUI hover) #308 — menu bar keyboard/hover dispatch gaps

[JDonaghy]

Plan filed (Session 353): See .claude/plans/lucky-launching-brook.md for the full implementation plan.

Blocked on: JDonaghy/quadraui#61 — ContextMenu::move_selection() + first_selectable() helpers. Once that lands, Steps 1-4 of the plan can proceed.

Summary of approach:

1. Add shared Engine::handle_menu_key() using quadraui's ContextMenu::move_selection()
2. GTK: remove bespoke overlay DA, draw dropdown on main DA during paint, push to ModalStack
3. TUI: replace 90-line bespoke keyboard nav with shared engine method, push to ModalStack
4. Cleanup: remove Msg::MenuHighlight, overlay DA fields, bespoke hit regions

[JDonaghy]

Session 353 — reverted. Three attempts at GTK-specific overlay DA code, each with different bugs (wrong position, wrong font, broken arrow keys, gap above dropdown). All caused by forked TUI vs GTK code paths.

Root cause: Not following the quadraui menu_bar_app example pattern. The example uses ONE shared dropdown_layout() function called by both backends with zero backend-specific code. Vimcode had separate overlay DA setup, Msg routing, click/motion handlers, and anchor math per backend.

Revised plan: Add render::build_menu_dropdown(menu_data, bar_layout, line_height, viewport) as the single shared builder. Each backend calls it and draws with draw_context_menu — 3 lines of thin wiring, not 100+ lines of forked handlers. See .claude/plans/lucky-launching-brook.md for details.

What's on develop from this attempt (kept):

• Engine::handle_menu_key() + MenuKeyResult enum + menu_dropdown_ctx/layout fields (Step 1 — correct, shared code)
• quadraui#61 landed: ContextMenu::move_selection() + first_selectable()