MOB-111: listener process — single inbound entry point from native

[GenericJam]

Third step of epic MOB-108. Follows #95 (MOB-109) and #96 (MOB-110).

Problem

Mob.Renderer named a screen process directly at ~35 call sites, one per interactive prop: nif.register_tap({screen_pid, tag}). That hard-wires the inbound path to whichever process rendered the tree, and it looked like the half of the epic that would force a native change.

It doesn't force one

nif_register_tap stores an arbitrary term as the handle's tag (enif_make_copy into the handle's own env) and the senders echo it back verbatim. So the tag can carry an envelope:

{listener_pid, {:mob_route, screen_pid, tag}}

Native delivers {:tap, {:mob_route, screen_pid, tag}} to Mob.Listener, which forwards {:tap, tag} to the screen. The screen sees exactly the message it saw before. No .m, .zig, or generator-template change — the epic's constraint.

:mob_screen is untouched: the back gesture, alert actions and launch-notification fallback resolve through enif_whereis_pid on both platforms, and MOB-113's router takes that name over, keeping the two changes separable.

The envelope carries a pid, not a ref

The epic sketched {listener_pid, {screen_ref, tag}}. Carrying the pid needs no registry and produces the behaviour the epic asked for: a handle registered by a screen that has since stopped delivers to a dead pid, which the BEAM drops, rather than landing in whatever screen is current with that screen's socket. That is the MOB-107 misrouting fix. A ref earns its cost at MOB-112, when a screen can restart and keep identity across a new pid.

A regression the review caught

The first commit unwrapped one shape, {event, tag}. Native has two families, and the second was silently dropped:

shape	senders
{event, tag}	mob_send_tap, mob_send_event, mob_send_scrolled_past
{event, tag, payload}	mob_send_change, mob_send_compose, mob_send_swipe_with_direction, mob_send_scroll, mob_send_drag, mob_send_pinch, mob_send_rotate, mob_send_pointer_move

That is every text field / toggle / slider on_change, every tab selection (on_tab_select is wired to mob_send_change_str), and every gesture stream — dead on both platforms, no crash, no log.

Two things let it through: the device verification was a button tap, the one shape that still worked; and the test double modelled only the 2-tuple family, so a test using :change passed while asserting the opposite of production behaviour.

Fixed in the second commit: a second handle_info/2 clause, FakeNative.fire/3 replaying the value-carrying senders, and a round-trip test for all eight. Unmodelled shapes now log at error instead of vanishing. No fourth arity exists — every enif_make_tuple4 in ios/mob_nif.m is a NIF return value, not a message.

Scope note

With one screen process the hop buys nothing on its own. The value is the indirection: the inbound path stops naming a screen process in 35 places, so MOB-112 and MOB-113 change one function. The escape hatch for high-frequency streams is simply not calling handler/1; nothing uses it, because the hop hasn't been measured.

Verification

• 20 new tests, including a round trip that replays what the native senders actually do
• Negative control: both 3-tuple tests fail without the clause
• Suite 1201 passed, format / credo --strict / --warnings-as-errors clean
• Device-verified on the broken path, not just a tap: typing into a text_field on the iOS simulator echoes on_change=Change wor back through the screen. Android's sendChange builds the identical 3-tuple. Earlier runs verified cold boot, first frame and taps on both platforms.

Found while verifying

mix mob.deploy hot-pushes over dist without writing BEAMs to disk, so changes revert on restart — filed as MOB-118 with evidence. That's the long-standing "deploy doesn't really work" behaviour, and why --native (which sets force_fs: true) always worked.