MOB-103: element_frames liveness — tree membership isn't rendered

[GenericJam]

Follow-up to MOB-102 (#87). Not ready to merge — see Verification.

Problem

MOB-102 replaced nif_set_root's wipe with a purge-by-id. That fixed static elements vanishing, but swapped the predicate: Mob.Test.element_frames/1 documents rendered on screen, purge-by-id implements present in the BEAM tree. Three divergences:

1. In the tree, not laid out.LazyVStack rows scrolled out of range, inactive TabView tabs, dismissed sheet content — the id stays in the tree so the purge keeps it, and onChange never fires again, so the last on-screen frame is reported forever. Scroll a 500-row list to row 200 and tap_id(node, "row_3") taps whatever is at those coordinates now. Pre-MOB-102 that was {:error, :not_found} — MOB-102 turned a safe failure into a silently wrong action.
2. Teardown race narrowed, not closed.mob_adopt_frame_ids runs on the NIF thread; MobViewModel.setRoot is DispatchQueue.main.async. Outgoing screens animate out under .move, firing onChange the whole way, re-registering at mid-animation coordinates after the purge ran.
3. Trackers aren't bound to an :id. Every ForEach keys children by index while the registry is keyed by :id, so a list delete shifts ids onto trackers that keep their identity.

Fix

Keeps purge-by-id, adds what it can't express:

• Compare-and-delete on .onDisappear — mob_register_frame returns a monotonic seq; a tracker can only delete an entry it still owns. Deliberately on the unregistration side; MOB-102's four rejected attempts were all registration-side.
• Generation gating — nif_set_root bumps a frame generation on identity-destroying transitions, in lockstep with navVersion. Superseded writes are refused, which is the only thing that makes the shared-:id nav case safe. Read via a plain C call, not @Environment/@ObservedObject — a rejection gate, not a repopulation trigger.
• Register on .onAppear and on .onChange(of: id) — makes disappear/reappear self-healing regardless of whether initial: re-fires, and handles the index-keyed-ForEach divergence order-independently.
• Bookkeeping in a reference box rather than @State scalars; nif_element_frames serializes outside the lock; mob_nif.m imports the bridging header so signature drift is a compile error.

Adversarial review

The first commit was reviewed adversarially; it found divergences 1 and 3 above as provable defects that reintroduced MOB-102's own bug, plus docs claiming more verification than had been done. The second commit fixes those and corrects the claims. Details in the commit message and decisions/2026-08-27-frame-registry-liveness.md.

Verification

Done:

• test/native/ — committed, runnable (make -C test/native run), 20 assertions including both MOB-102 non-regression cases, the shared-:id nav case, and the list-delete case. It reproduces the registry functions rather than linking the shipped ones, so it checks the algorithm, not the binary.
• ios/mob_nif.m compiles clean (clang -fsyntax-only -fobjc-arc, iOS 26.5 sim SDK, MobApp-Swift.h stubbed since swiftc generates it during the real build).
• clang-format, swiftlint (one pre-existing force_cast on master), 1111 Elixir tests — though the only Elixir change here is a docstring.

Not done, and it decides whether this is a fix or a regression: whether .onDisappear fires for a LazyVStack row leaving the render window (and whether LazyVStack destroys those rows at all rather than retaining them), whether a TabView round trip re-registers, and whether app backgrounding fires a spurious .onDisappear that could empty the registry. None is answerable from source; there is no XCTest target here. Needs a simulator pass reading element_frames/1 over dist at each step.

No version bump — CHANGELOG entry is under [Unreleased].

🤖 Generated with Claude Code

[GenericJam]

Device-verified — the headline claim now holds in practice

The adversarial review's verdict was that no amount of source reading decides whether this is a fix or a regression. Ran it on both an iPhone 17 Pro simulator (iOS 26.4) and a physical iPhone (iOS 26.5.2), using a generated probe app (300-row :list, plus two screens deliberately tagging a button with the same :id), read over dist with Mob.Test.element_frames/1.

Scenario	Simulator	Physical iPhone
Divergence 1 — lazy-list row scrolled out of range	✅ row_3 absent	✅ row_3 absent
MOB-102 non-regression — static unmoved element	✅ survives	✅ survives
Divergence 2 — shared :id across a nav push	✅ y=512 (incoming), not 112	✅ y=470.5 (incoming), not 70.5
Background / foreground	✅ registry intact	—
MobTabView tab switch	❌ not reached	❌ not reached

The load-bearing assumption holds. Only the visible window is ever registered — 12 of 300 rows on the simulator, 10 on the phone — so LazyVStack really does destroy far-offscreen rows and .onDisappear really does fire for them. That was the review's biggest "if this is wrong, nothing is fixed while the docs claim it is" risk. Rows scrolled back into range re-register, so the cycle is self-healing.

Worth being explicit about why row_3's absence is attributable to this change: under MOB-102 alone its id is still in the tree (all 300 items are), so the purge would never drop it and nothing else would either.

Divergence 2 — the one the review called nondeterministic — reports the incoming screen's frame on both targets, stable across repeated reads seconds after the animation settles, and restores exactly on pop. Neither deleted nor left at mid-animation coordinates.

Still open

MobTabView. A tab switching away keeps its subtree in the tree, and TabView preserves view identity across switches, so whether .onAppear re-fires on re-selection is not settled by the lazy-list result — that path destroys and rebuilds instead. The probe couldn't reach it (tab_bar/1 navigation didn't render a tab bar in the generated app), so it stays documented as open rather than being folded into the verified set.

[GenericJam]

MobTabView verified — last open scenario closes

Step	Registered ids
start (tab A active)	tab_a_marker only
switch → B	tab_b_marker only — A dropped
switch → A	tab_a_marker only — A restored
switch → B	tab_b_marker only

Repeatable in both directions. .onAppeardoes re-fire on tab re-selection, so a tab round trip is not permanently unreportable — that was the review's specific worry, and it doesn't occur. The deactivated tab's element is dropped rather than left stale.

Two things found getting there, both recorded in the decision doc:

• The reachable path is the tab_barrender node (props.tabs + props.active), not Mob.App.tab_bar/1 navigation.
• Mob.Renderer has no on_tab_select handler, so that prop reaches native as a raw {pid, tag} tuple and kills the screen process on serialize. Tab selection must be driven from Elixir via active. Separate pre-existing bug, not this change's — worth its own issue.

MobTabView is the only scenario left simulator-only: the phone had rebound dist to its USB link-local address (169.254.1.100), which dist can't route to. Every other scenario ran on both targets and agreed exactly.