Focus requests reach widgets clipped by a scroll viewport, and stop retrying after a few frames

A scroll viewport keeps in `widget_rects` only the widgets at least partly inside its visible area (`draw/layout.rs`, the translation of the sub-canvas rects to surface space). A focus request whose target sits below the fold therefore never finds it: `App::take_focus_request` was honoured only for widgets already laid out on screen. The Wi-Fi page of settings is one such case by construction: tapping a secured network inserts the password form under the row and asks for focus on the field, so for a row in the lower part of the list the field is born outside the viewport and the request misses. Worse, the miss branch parked the id in `focus_retry`, marked the view dirty and requested a redraw on every iteration, so the application rebuilt and repainted at the compositor's frame rate for as long as the widget stayed hidden.
The layout pass now records the widgets it drops for carrying a `WidgetId`: `DrawCtx::scroll_clipped` holds `(id, scroll flat_idx, rect)` with the rect in the scroll's content coordinates, the same frame the navigable-item list uses, and `draw_frame` hands it to `FrameState`. When a focus request misses, `AppData::reveal_clipped_widget` looks the id up in that list on the main surface and the overlays, finds the viewport in `scroll_rects`, and moves its offset on the axes the scroll allows so the rect lands inside; the next frame lays the widget out and the retry focuses it. Nested scrolls resolve one viewport per frame.
The rule that computes the new offset is `scroll::offset_into_view`, extracted from the keyboard navigation in `input/keyboard/nav.rs`, which now calls it instead of carrying its own copy; unit tests cover the three cases.
`focus_retry` carries a budget of drawn frames (`FOCUS_RETRY_FRAMES`, four), decremented only on iterations that actually drew, so a request made while a frame callback is pending does not lose its chance. A fresh request from the application replaces a pending retry with a full budget. When the budget runs out the request is dropped, which ends the redraw loop for a widget that never appears.
Documented in the `take_focus_request` doc comment, the cookbook and the changelog; Debian revision 0.3.0-3.

src/event_loop/app_data.rs

@@ -271,8 +271,9 @@ pub struct AppData<A: App>
 	/// Used to drive `App::on_first_frame_committed` exactly once.
 	pub first_frame_committed: bool,
 	/// Focus request deferred because the target widget was absent from
-	/// `widget_rects` (e.g. read_only, not yet rebuilt). Retried next draw.
-	pub focus_retry: Option<crate::types::WidgetId>,
+	/// `widget_rects` (not yet rebuilt, or clipped by a scroll viewport),
+	/// with the number of drawn frames it may still wait for.
+	pub focus_retry: Option<( crate::types::WidgetId, u8 )>,
 	/// Runtime performance guardrails (stuck-animation / poll-interval
 	/// diagnostics and the software animation-rate cap). See [`super::perf`].
 	pub perf: super::perf::PerfState,