configurator/shim: drain tty without hanging (use -t 0.05, not -t 0)

bash's `read -t 0` only TESTS whether input is available; it does not
consume the bytes. So the drain loop `while read -t 0 ...; do :; done`
spun forever the moment any bytes were pending (e.g., the DSR reply
sitting in the tty input buffer after gum style sent CSI 6n).

That hung the configurator at the first step() title screen — blank
prompt, blinking cursor, no keyboard form.

Use `read -t 0.05 -N 9999` once, which consumes up to 9999 bytes with
a 50ms timeout. Always returns after 50ms whether there's data or not.
Single call replaces the while loop.

configs/airootfs/root/.automated_script.sh

@@ -38,9 +38,10 @@ mkdir -p /var/log
 touch "$OMARCHY_INSTALL_LOG_FILE"
 
 # Drain any stale terminal input (e.g., cursor-position-report responses left
-# in the kernel tty input buffer by archiso's boot init). If we don't, the
-# first gum invocation can echo them as visible "^[[13;1R" artifacts.
-while IFS= read -r -t 0 -n 1024 _drain </dev/tty 2>/dev/null; do :; done
+# in the kernel tty input buffer by archiso's boot init). `read -t 0` only
+# tests for input; we need a small positive timeout so the read actually
+# consumes bytes and then returns.
+read -r -t 0.05 -N 9999 _drain </dev/tty 2>/dev/null || true
 
 cd /root
 ./configurator >/dev/tty 2>/dev/tty

configs/airootfs/root/configurator

@@ -17,7 +17,10 @@ abort() {
 # that gum's TUI startup sends but doesn't always consume. Without this,
 # bytes like ^[[13;1R show up next to step titles.
 _drain_tty() {
-  while IFS= read -r -t 0 -n 1024 _drain </dev/tty 2>/dev/null; do :; done
+  # Consume up to 9999 bytes of pending tty input with a short timeout.
+  # `read -t 0` only TESTS for input; it doesn't consume — that pattern
+  # hangs forever the moment any data is actually pending.
+  read -r -t 0.05 -N 9999 _drain </dev/tty 2>/dev/null || true
 }
 
 step() {