fix: a modal can act on a key pressed against the frame before it

[AbysmalBiscuit]

egui delivers a frame's input events for keys pressed against the frame
before it. A modal that opens and consumes keys in the same frame can
therefore act on a keypress aimed at whatever was on screen previously.

The shape

A handler opens a modal and, in that same frame, calls the shared key
consumption helper. The events it receives were produced while the previous
frame was on screen, when the modal did not exist. A key the user pressed at
the terminal, or at a different dialog, lands on the confirm button of a
dialog they have not seen yet.

The same hazard appears in a second form: a modal whose content changes
when an async result lands can consume a key pressed against the frame that
showed the old content.

Where it stands

The delete dialog's keyboard path is fixed: it handles the confirm before
adopting a landed dirty count, so a keyboard confirm always executes the
force value that was painted.

The rest of the pattern is not.

• show_create_dialog and show_close_session_dialog consume confirm keys
  in the frame they open.
• The delete dialog's mouse Delete button is still evaluated after the
  dirty count is adopted, so a pointer release landing on the exact frame
  the probe resolves runs against a warning that was never painted. One
  frame wide, and unlike a held key it does not repeat, so it is far
  narrower than the keyboard case was.

Why it matters

Most of these confirm something recoverable. The delete path is the one
where a stray Enter discards uncommitted work, and that specific case is
closed. What remains is a general correctness gap: no modal in the app can
currently promise that a confirm executed what the user was looking at.

What done looks like

One guard, applied where modals are opened rather than repeated per dialog:
a modal ignores input events belonging to the frame before it appeared, and
a modal whose content changed this frame ignores input belonging to the
frame that showed the old content.

Doing this generically is worth more than fixing the two named dialogs,
because the next modal added inherits the fix instead of the hazard.

[AbysmalBiscuit]

Branch fix/modal-stale-input (2b03dd32), pushed to AbysmalBiscuit/alacritree, stacked on feat/schema-action-names (PR mathix420#205). No PR open yet.

One guard where modals read keys, not eleven per-dialog patches. modal_gate.rs remembers which modal the previous frame painted; consume_modal_keys now takes that gate plus the modal's identity and answers (false, false) unless the same modal was on screen when the keys were pressed. All eleven call sites pass their kind.

Every screen a user must be able to tell apart before answering is its own kind, so the create dialog's prompt, running and done screens are as separate as unrelated dialogs. That closes the content-change form: the done screen no longer acts on a key pressed at the running screen.

The keys still leave the event queue when the gate refuses. Letting a refused Enter fall through would type it into the shell the modal just covered, which is worse than swallowing it.

Two things left open.

The mouse case does not exist on this branch's base, where req.dirty is a plain DirtyCounts resolved before the dialog opens. The async adoption that creates the window lives on perf/nonblocking-ui. In integration/all-features, where both meet, the delete dialog's identity is still just ModalKind::Delete, so a dirty count landing mid-dialog does not re-gate. Closing that needs the adopted count folded into the modal's identity, on whichever branch owns the async count.

The integration/all-features copy is a cherry-pick (3c1189ee), not a merge: this branch descends from the GPU-grid stack behind PRs mathix420#203 and mathix420#205, none of which is in that integration branch.