MOB-110: sender process — serialise render and the tap-table commit

[GenericJam]

Second step of epic MOB-108. Follows #95 (MOB-109).

Problem

Mob.Screen.do_render/4 called Mob.Renderer.render/4 inline, so rendering happened in whichever process handled the message. That is safe today only because there is exactly one screen process — MOB-112 makes screens processes, and then two can render at once.

The native contract does not tolerate that. ios/mob_nif.m:

staticTapHandletap_tables[2][MAX_TAP_HANDLES];
staticinttap_active=0;
staticinttap_build_count=0; // cursor into the BUILDING table

The double buffering protects a concurrent reader — a drag arriving mid-render resolves against the last committed table. It does nothing for concurrent writers: one global build cursor means two renders in flight interleave their handles into the same building table, and whichever reaches set_root first commits a table holding both screens' handles while the other screen's tree is never committed at all.

Change

Mob.Sender is the only caller of the render NIFs. Screens still build their own tree — Composite/List/Component expansion all take self() — and hand the finished tree over. Mob.Renderer uses self() nowhere outside doc examples, so the sender can own the whole call.

Queueing rather than executing in the caller buys coalescing: only the newest tree per screen is committed, and a tree for a non-active screen is dropped. That second half is what will let an inactive tab hold state without rendering.

No .m or .zig change — this is entirely about who calls the existing NIFs.

Rationale in decisions/2026-08-28-sender-serialises-render.md. The invariant is now in AGENTS.md's pre-empt-failure rules, since it is easy to break by accident and the failure mode (one screen's tree silently never committing) is hard to diagnose.

A bug the tests caught

The first sync/1 relied on the render's self-sent :flush being queued ahead of a later sync call. A self-send appends to the back of the mailbox — behind a sync the caller already queued — so sync/1 returned before the frame was committed. Five tests failed on it. sync/1 now performs the flush itself, which also strengthens coalescing.

Review

An adversarial pass found six more, all fixed in the second commit:

• set_active/1 on every render let any screen promote itself. At MOB-112 a background screen's timer would commit over the foreground one, disarming the mechanism this step exists to build. Now called only where navigation establishes the active stack.
• A documented boot path rendered nothing silently — liveview_notes.md skips Mob.App, and casts to a missing sender are :ok. Mob.Screen.init/1 now ensures the sender, started unlinked.
• Coalescing swallowed nav transitions — a :push superseded by a :none re-render lost its animation.
• sync/1's 5s default would newly kill the screen on a slow frame; Mob.Screen passes :infinity.
• Mob.Test's documented sync point broke for the native-reading helpers. Added Mob.Test.settle/2.
• The moduledoc still taught the rejected buggy design.

Two findings are carried into MOB-112 and recorded in the ADR: ComponentRegistry.reconcile/2 runs screen-side and destructively before the commit, and the sender has no supervisor.

Verification

• 20 new tests, including the screen↔sender wiring the review found untested
• Suite 1181 passed, format / credo --strict / --warnings-as-errors clean
• Device-verified both platforms, since this changes when the first frame is committed: sheetprobe cold-started on the iOS simulator (BEAM log to step 5 => ok) and the Android emulator, both rendering the first frame through the sender, and a tap presented a sheet on each

Scope note

Coalescing is not observable in production yet — with one screen process the synchronous call paths flush every render. It becomes load-bearing at MOB-112, which is also when the serialisation stops being redundant.