Experiment: retire the native-ref fast path (delete a whole matrix row)

[thymikee]

Follow-up from the ADR 0011 work and the dead-code audit (2026-07-04).

Post-#1082, native-ref (backend.tapTarget/fillTarget for click/fill @ref) and runtime-ref consume the same stored session snapshot: the fast path now runs the shared preflight daemon-side and then pays a runner round trip for live re-resolution, where the runtime path would instead do a coordinate tap from the node it already validated. The fast path's remaining value proposition is runner-side live element re-resolution (element moved since snapshot → tapTarget still hits it; a coordinate tap would miss).

Hypothesis: with refs being short-lived by convention (STALE_REF hints, freshness machinery) the live-re-resolution win is rare enough that the path no longer pays for its existence — and deleting it removes an entire row from the guarantee matrix (the most durable erosion fix available), plus hasNonDefaultTapOptions, the backend tapTarget/fillTarget surface on iOS, and their runner protocol arms.

Experiment before believing it:

1. Run the react-navigation Maestro suite (185 tapOns) with the native-ref path force-disabled (route @ref clicks through runtime-ref), compare pass rate and duration.
2. Same on the repo's replay/smoke suites.
3. If parity holds: deprecate behind a kill-switch env for one release, then delete.

Origin of the path is Maestro-replay reliability, so the Maestro suite is the deciding oracle. Do not delete on inspection alone.

[thymikee]

Baseline recorded (2026-07-04, merged main at 415f599, iPhone 17 Pro sim, dev build + Metro):

38/38 flows PASS via agent-device replay --maestro, wall times 9–19s per flow (median ~14s), full suite ~9 min sequential. This is the control arm for the experiment: the next run should be identical except with the native-ref fast path disabled (route click @ref/fill @ref through runtime-ref), comparing pass rate and per-flow durations.

Harness for reproduction: flows from react-navigation/example/e2e/maestro with -e APP_ID=org.reactnavigation.playground -e APP_SCHEME=rne://, isolated AGENT_DEVICE_STATE_DIR, Metro on default 8081 (nothing else may hold that port), app bundle prewarmed before the loop, and no other session holding the device (a leftover session produces instant DEVICE_IN_USE failures across the board — the error hint correctly points to close --session).

[thymikee]

Experiment resolved — by inspection that invalidated its premise, not by the B-arm run.

Preparing the B-arm surfaced that the native-ref fast path is web-only in production: tapTarget/fillTarget appear zero times in the apple/android platform code; the sole wiring is webProvider?.clickRef in src/daemon/handlers/interaction-runtime.ts. The hypothesized iOS runner round trip ("live re-resolution vs coordinate tap") does not exist — on iOS, click @ref always takes the runtime-ref path already. Running the Maestro suite with the path "disabled" would have compared identical binaries and produced two green runs masquerading as evidence.

Verdict:

• No iOS retirement candidate exists. The A-arm baseline (38/38, recorded above) remains useful as a general replay-suite regression baseline.
• Web's clickRef stays — a stable DOM-handle click is the efficient and reliable primitive there; retiring it would be a regression.
• The registry row now records the web-only reach (docs: native-ref dispatch path is web-only in production #1095) so the matrix stops implying mobile coverage.

The meta-lesson mirrors this issue's own warning inverted: "do not delete on inspection alone" — but also do not measure before checking the code path can fire. Closing.