Unified dialog and context menu rendering across backends

[JDonaghy]

Context

GTK uses native widgets (PopoverMenu, custom dialog popups) for dialogs and context menus, while TUI and Win-GUI render them from shared engine data (engine.dialog, engine.context_menu). This causes visual inconsistency — the Win-GUI and TUI look similar, but GTK looks noticeably different.

Current state:

Component	TUI	Win-GUI	GTK
Dialogs	Drawn from engine.dialog ✅	Drawn from engine.dialog ✅	Native GTK popup ❌
Context menus	Drawn from engine.context_menu ✅	Drawn from engine.context_menu ✅	Native PopoverMenu ❌
Close-last-dirty-tab	Shows overlay, no-op on close	Shows overlay, no-op on close	Native dialog, triggers quit flow

Goal

GTK should draw dialogs and context menus the same way TUI and Win-GUI do — onto the DrawingArea using the engine's data structures. This ensures:

1. All 3 backends look visually consistent
2. Changes to dialog/menu rendering only need to be made once
3. Click handling uses the shared resolve_dialog_click() / resolve_context_menu_click() functions from Hit regions for context menus + dialogs #43

Scope

• Dialogs: GTK should render engine.dialog onto the DrawingArea (like draw_diff_peek_popup etc.) instead of using a separate GTK overlay. Remove dialog_btn_rects pixel cache in favor of shared hit regions.
• Context menus: GTK should render engine.context_menu onto the DrawingArea instead of using PopoverMenu. The engine already has the item list and selected state.
• Close-last-tab behavior: All backends should behave the same when closing the last dirty tab (either offer quit or create an empty tab).

Dependencies

• After Hit regions for context menus + dialogs #43 (context menu + dialog hit regions — shared resolver functions)
• Related to Unified sidebar rendering via ScreenLayout #133 (unified sidebar rendering — same principle)
• Before Abstract event layer (UiEvent) #44 (abstract event layer)

[JDonaghy]

Implemented in PRs #137 (context menus) and #138 (dialogs)