[danczw]

Summary

 Modal::ask
-  show question
-  arm
-  wait                      # parked: a resize is not drawn until a key answers
+  loop
+    show question           # false → abort(UNDRAWN), as for a pane too small
+    arm                     # after the draw, every time
+    wait
+      Resized → loop again  # keys typed against the old frame are forgotten
+      other   → break
   clear

 key thread (sandbx-tui-input::read)
-  poll(tty, no timeout)           # crossterm sees SIGWINCH only inside its own poll
+  poll(tty, 100 ms)               # so it is asked every 100 ms, key or not
   source.next()
-    Event::Resize → ignored
+    Event::Resize → Wire::resized() → wakes Answers::wait with Reply::Resized

A resize outranks a queued key in wait and yields to an interrupt or a hangup.
A key pressed in the up-to-100 ms gap before the reader notices still answers the old frame, and SECURITY.md says so.

Evidence

• Before: a_reader_with_nothing_typed_still_looks_for_a_resize fails: the reader never looked without a key: Timeout.
  After: it passes, with a_resize_redraws_the_question_and_asks_again (show, arm, wait, show, arm, wait, clear), a_resize_that_leaves_no_room_for_the_question_aborts, and the Wire tests for ordering, wake and the race between draw and arm.

Reviews: /code-review high at 5707693 found the reader never saw a real resize, fixed in d1da7d3; the stale-flag, dead-arm and drag-resize findings are declined as harmless or fail-closed.
/security-review at d1da7d3: no findings.
Comment pass at a13ed3d: nothing to cut.
Not covered by a test: a real SIGWINCH through crossterm, which the pty fixture cannot send.

Merge Danger

Door: two-way

Blast Radius: tui --approve call only

Reply gains a variant, recorded in crates/sandbx-tui-input/public-api.txt.
The reader now wakes every 100 ms while idle.

Closes #508