iris: a tap on an empty text field left no caret, so typing was silently dropped

TextEditCtx::select compared the tap against the laid-out text's own box
and cleared the selection for anything outside it. An empty field lays
out to a zero-width box, so tapping the composer granted focus and opened
the keyboard with no caret, and insert_str returns early without one --
every keystroke went nowhere and no glyph was ever emitted. Parley clamps
a point outside the layout by itself, and a press reaching select() has
already been hit-tested to the widget, so there was nothing for the
'outside' branch to mean.

insert_str now debug_asserts rather than dropping input silently, and
UiRenderState::draw_started -- a re-entrancy guard whose test was written
after its own remove(), so it could never fire, and which grew by one
entry per widget ever drawn -- is restored to what it was meant to be:
inserted around Widget::draw, removed when it returns, asserted empty at
the top of every update.

docs/IRIS_TODO.md

@@ -162,8 +162,33 @@ agent takes them without colliding with that pass's `bench_client.rs`/
   genuinely new renderer -- see IRIS.md's 2026-09-06 entry and RUST.md's
   P0 box, item 4. Verified on the emulator (home, reopen, screenshot);
   not yet on the phone.
-- [ ] **Composed/typed text never becomes visible at all -- found
-  2026-09-06, not fixed.** The composer bar stays empty even once the
+- [x] **Composed/typed text never becomes visible at all -- root-caused
+  and fixed 2026-09-06.** Not the renderer at all: **the composer's buffer
+  was empty the whole time.** `TextEditCtx::select` (`iris/src/widget/
+  text/edit.rs`) compared the tap against the *laid-out text's* box and
+  set `selection = None` for anything outside it -- and an empty field's
+  layout is a zero-width box, so tapping an empty composer granted focus
+  and opened the keyboard while leaving no caret; `insert_str` returns
+  early with no caret, so every keystroke after that was dropped in
+  silence. Gboard's suggestion strip is its own composing state, not a
+  read of our buffer, which is what made the earlier pass conclude the
+  buffer held the text. Fixed by letting parley clamp a tap outside the
+  layout to the nearest cursor position (a press that reaches `select`
+  has already been hit-tested to the widget, so there is no "outside"),
+  plus a `debug_assert!` in `insert_str` so an insert with no caret fails
+  at the mistake instead of dropping input -- it immediately caught
+  `layout_tests::composing_text_after_a_keyboard_resize_...` typing into
+  an unfocused field. Three new tests in `edit.rs`
+  (`tapping_an_empty_field_places_a_caret_so_typing_lands`,
+  `tapping_past_the_end_of_the_text_clamps_to_the_end`,
+  `dragging_without_a_previous_selection_selects_nothing`); the first
+  fails on the pre-fix code. Emulator evidence: `adb shell input text`
+  after `tap 'Message'` now shows the text in the bar
+  (`/tmp/final-typing.png`) and logs `iris text render: chars=5 ...
+  glyphs=5`, against `glyphs=0` on every keystroke before.
+
+  **The old, superseded diagnosis, kept because it was wrong in an
+  instructive way:** The composer bar stays empty even once the
   buffer genuinely holds the typed text (confirmed indirectly: Gboard's
   own suggestion strip reacts correctly to each keystroke). A new unit
   test proves the widget tree's own layout math resolves the field's