Native host key dialogs confirm on Return, and the plugin makes the obvious fix unsafe #175

Tested against main (894ea12), tauri-plugin-dialog 2.8.0, rfd 0.16.0. Found during an IPC audit; not fixed yet because the safe fix needs native verification on all three platforms.

Return confirms "Trust the new key"

host_key_prompt::show (desktop/src-tauri/src/host_key_prompt.rs) builds the dialog with OkCancelCustom(confirm_label, "Cancel"), so the confirm button comes first.

• macOS: rfd adds the buttons to an NSAlert in that order, and the first button is the Return-key default.
• Windows: rfd's TaskDialog uses nDefaultButton: 0, which is also the first button.

So "Trust the new key" and "Forget the key", plus the host-change prompt #122 adds through the same function, fire on a stray Enter. These are the two places where Clavyn decides whether a server is who it claims to be. A page that writes "press Enter to reconnect" into a terminal, while a held key change is pending, gets the key pinned by the user's own keystroke.

Why swapping the buttons is not the fix

show_message_dialog in the plugin (desktop.rs) remaps rfd's results on every platform:

(rfd::MessageDialogResult::Cancel, MessageDialogButtons::OkCancelCustom(_ok, cancel)) => Custom(cancel)

rfd reports closing the dialog or pressing Escape as Cancel (on Windows and Linux at least), and the plugin turns that into "the second button was pressed". With OkCancelCustom("Cancel", "Trust the new key"), closing the window would therefore confirm. The current order is the only one where dismissing the dialog is safe.

Options

1. Call rfd directly (rfd::AsyncMessageDialog) instead of going through the plugin. Then Cancel/close stays Cancel, and the order can put Cancel first. Needs a check on each platform of which button Return and Escape hit.
2. Keep the plugin and refuse an answer that arrives within ~500 ms of the dialog opening, as Unavailable rather than Declined so no cooldown starts. That catches the reflex Enter, but it is a heuristic.
3. Ask in two steps, e.g. the native dialog asks the user to type or select the last characters of the presented fingerprint. That is closest to OpenSSH, which wants yes typed out, but needs UI work.

Whatever the choice, it must be checked with the native-e2e skill on macOS, Windows and Linux: Return, Escape and the window close button each need to give the expected answer.