fix(dash): only act on key Press events in overlay dispatch

[michaelroy-amd]

Problem

In both the bare-`rocm` launcher (focused Serve a model) and the full dash, you could not select a model in the serve wizard's recipe picker. Pressing Enter on a highlighted model re-opened the picker with that model pre-filled as the filter query instead of choosing it — so the model was never actually selected and the serve could not proceed.

Root cause

The dash event loop (crates/rocm-dash-tui/src/app/mod.rs) dispatches each operational overlay (serve wizard, engine manager, onboarding, …) directly to its on_key via if state.<overlay>.is_some() match arms. Those arms run before the general handle_key, which was the only place filtering out non-Press key events.

Terminals that also emit Release/Repeat key events (Windows Terminal / ConPTY under WSL, and any terminal with the kitty keyboard protocol) therefore delivered each keystroke to overlays twice:

1. Press → picker chooses the model → picker closes, model field filled.
2. Release/Repeat echo → focus is back on the Model field, so Enter re-opens the picker seeded with the just-chosen model id as the filter query.

The model picker itself was correct; the bug was purely in the event-loop wiring, which is why it hit both front ends (they share the loop).

Fix

• Extract is_actionable_key(KeyEventKind) -> bool (Press only).
• Add a top-priority match arm that swallows non-Press key events above every key arm, so the Press-only invariant now covers the overlay dispatch too.
• Route handle_key through the same predicate (DRY with the existing release_events_are_ignored behavior).

The mouse path was audited and is immune to the same "one action → multiple events" class: resolve_mouse only acts on Down(Left) and the four scroll kinds. The only two terminal event-reading sites are this loop and the launcher loop (which already filtered to Press) — both are now covered.

Test plan

• only_press_key_events_are_actionable (new) and release_events_are_ignored pass
• cargo test -p rocm-dash-tui app-module suite (156 tests) green
• cargo clippy -p rocm-dash-tui --all-targets -- -D warnings clean
• Manual: in the launcher Serve a model flow and the dash serve wizard, Enter on a highlighted recipe selects it (verify on Windows Terminal / WSL where the double-fire reproduced)

[rominf]

Reviewed the change and verified the behavior manually — the model picker now selects on Enter in both the launcher serve flow and the dash serve wizard. LGTM.

The diagnosis is right: the overlay dispatch arms in event_loop call their on_key directly and never filtered KeyEventKind, while the general handle_key already dropped non-Press — so overlays double-fired on terminals that emit a second event per keystroke. A single Press-only swallow arm above all key arms closes the gap, and routing handle_key through the same is_actionable_key predicate is a clean DRY-up. Nice test coverage with only_press_key_events_are_actionable.

I checked the obvious worry — that swallowing Repeat would break held-key auto-repeat (scrolling a job console, holding Backspace in a field). It doesn't: the app never pushes PushKeyboardEnhancementFlags, so the unix backend never emits Repeat; OS auto-repeat arrives as repeated Press and stays actionable; and the pre-existing handle_key already dropped non-Press, so overlays are just being brought in line with the rest of the UI.

A few optional, non-blocking nits:

1. app/mod.rs:1671 — let _ = k; is redundant. k is already used by the guard, so an empty arm body (=> {}) compiles cleanly without an unused-binding warning.
2. app/mod.rs:1670 — the Press-only invariant for overlays now relies on this arm staying first among the key arms; a future key arm inserted above it would silently re-introduce the double-fire. Not a problem today, just worth a note near the arm (which the comment already partly does).
3. ui/launcher.rs:279 still hardcodes k.kind != KeyEventKind::Press rather than the new is_actionable_key. Fine as-is (separate module/loop), just means the "shared gate" is shared only within mod.rs.

None of these block. Approving.