Add typed serial settings operations

Route bounded admin mutations through the existing administration
dispatcher,
covering apply, lifecycle, persistence, authorization, and result
tracking.
Add the browser controls, automatic result refresh, regression coverage,
and
phase documentation.

tests/web_ui_session/README.md

@@ -48,11 +48,60 @@ Coverage:
 - Read-only admin Settings/Serial: 10 selection cycles preserve both sockets/IDs,
   drain hidden output and block terminal input; exact eight-field/256-byte schema,
   explicit refresh, error/timeout containment, late cancellation/restore/identity,
-  and concurrent serial reconnect without superseding admission. **21 Node groups total.**
+  and concurrent serial reconnect without superseding admission.
+- 8D.9 typed Serial actions: draft validation, Reset-only confirmation, bounded
+  JSON/CSRF, explicit working/persisted effects, automatic bounded result checks,
+  failure/timeout containment, session fencing and preserved sockets/writer identity.
+- Lost-acknowledgement and replaced-result uncertainty survives repeated result
+  checks, failed reads, refresh and navigation; a newly acknowledged explicit
+  submission starts a new result context.
+- Immediate completion on the first GET, pending then completion, 10-attempt
+  exhaustion and manual recovery, 15-second overall abort during fetch/body reads,
+  delayed timers/replies, automatic read errors, visible stale snapshots during
+  refresh and after refresh failure for every terminal outcome, late refresh
+  cancellation, no routine confirmations and Reset cancellation. Navigation,
+  pagehide/restore, logout, expiry and changed identity cancel checks without
+  automatic resumption.
+- Repeated current Settings selection is a no-op during submission, between and
+  during result checks, and during completion refresh: requests, timers, visible
+  values/control state, final outcome and socket/writer identity remain intact.
+  **35 Node groups total.**
+
+## Automatic result-check budget
+
+After a valid POST acknowledgement, the UI waits **1,000 ms** before the first
+result GET and between completed pending-result checks. It makes **at most 10
+GET attempts** and uses an independent **15,000 ms overall deadline**, measured
+with the monotonic browser clock from acknowledgement. Each attempt first
+revalidates the session; that time is included in the deadline. There is only
+one automatic check in flight. Delayed timer callbacks and replies also check
+this deadline. Expiry actively aborts the in-flight request and releases the UI
+for manual recovery; late completions cannot update the view.
+
+The first limit reached stops automatic checking. A read error also stops it.
+The budget does not cancel backend work and is not a server execution deadline.
+**POST is never automatically retried.** Lost acknowledgement requires explicit
+Check Result recovery; manual checks do not restart automatic polling. Exhausted
+or cancelled polling never resumes on navigation or bfcache restoration.
+
+Every known terminal result, including failure/cancellation, triggers one working
+snapshot refresh while retaining the operation outcome and any uncertainty
+warning. Snapshot refresh is outside the auto-check budget and retains the
+existing 15-second per-request bound (session validation and snapshot GET are
+separate requests). Settings remain visible but conflicting controls are disabled
+during work; old snapshots are explicitly stale during pending/uncertain work or
+a failed refresh. A successful refresh replaces the browser draft. Only Reset
+asks for confirmation, specifically because it overwrites saved configuration.
+
+Tests use a deterministic clock and individually fired timer callbacks, including
+callbacks invoked after cancellation and fetch/body doubles that ignore abort.
+These deliberately exercise fences beyond normal browser cancellation behavior.
 
 ## Integration and known gaps
 
-This covers 8D.3 session behavior, the 8D.6 selector and 8D.8 Settings. The renderer
+This covers 8D.3 session behavior, the 8D.6 selector, 8D.8 Settings and the 8D.9
+Serial UI. Operation responses are fetch doubles, not end-to-end execution of
+`web_serial_settings.c`, dispatcher work, serial reconfiguration or NVS persistence. The renderer
 still relies on its caller to authenticate resources; protected asset failures
 must be 401, never a redirect to HTML served as JavaScript. No Basic fallback is
 implemented here. Existing 8D.5 server authorization/protocols are unchanged.