GTK rasteriser dialog spawns without keyboard focus — must press → first to claim it

[JDonaghy]

Repro

1. Right-click any file in the explorer tree.
2. Click 'Delete' — the cairo-painted in-editor 'Confirm Delete' dialog appears.
3. Try to press Tab / ←/→ to move between buttons. Nothing happens.
4. Press → once. Now Tab / ←/→ work and cycle the buttons normally.

Expected

The dialog grabs focus on spawn so Tab / ←/→ / Enter / Escape work immediately. The first button (typically default-action) should be highlighted.

Actual

Dialog renders but is inert until → is pressed once. After that, normal keyboard navigation works.

Affected dialogs

All cairo-rasterised in-editor dialogs (the ones that go through quadraui::gtk::draw_dialog via screen.dialog) — Confirm Delete, Confirm Move, File Changed, Code Actions, Extension Remove, etc. The native-window dialogs (gtk4::Dialog::with_buttons, e.g. Rename) are not affected — those handle focus through GTK's normal widget tree.

Suspected scope

The rasteriser dialog is keyboard-input-driven through the engine's dialog state machine (engine.dialog). Something in the GTK key-event routing requires an initial key press to claim ownership of the dialog state. The first → press doesn't actually move focus — it primes the dispatch.

Likely candidates:

• engine.dialog is set but the GTK key handler doesn't recognise the dialog as the active modal until an event lands.
• The 'selected button' index is not initialised on dialog spawn (no button has the highlight).
• ModalStack push happens but focus indicator state lags.

Surfaced during

#267 smoke test (refactored quadraui::gtk::draw_dialog to single-Pango-layout signature). Bug is preexisting — the refactor only changed font rendering inside the rasteriser, not input/focus dispatch.

Likely fix location

src/gtk/mod.rs Msg dispatch around dialog spawn, or engine/panels.rs show_dialog initial-state setup.