Selector queries have no fallback producer on the iOS Simulator, and any fallback needs producer equivalence

Leggi prima #2197 e #2273 per comprendere il contratto dello snapshot di Simulator e la distinzione tra i fallimenti delle query tipizzate. Poi segui il produttore principale dello snapshot, il suo private-AX fallback e il percorso della query del selettore. Il lavoro è completato quando le query di fallback preservano la corrispondenza per identifier e label, segnalano i veri negativi con lo stesso codice di errore e rispondono in modo coerente prima e dopo il degrado.

Split out of #2273 at triage request, to keep that issue scoped to the typed failure contract.

What this asks for

A selector query on the iOS Simulator has no fallback producer. Where the snapshot path degrades,
snapshot switches to the private-ax producer and still returns the element, and a selector query
for that same element fails.

This issue tracks giving the selector path a fallback, and the equivalence it would have to hold.

The observation behind it

Measured on agent-device 0.20.10, iOS Simulator, in a remote EAS Simulator session. Full method
and diagnostics are in #2273.

Six screens, 30 is visible calls each. Three screens answered every call. Three answered almost
none, all with XCTEST_RECORDED_FAILURE.

The split follows one thing only, which each capture states in its own header.

Node count does not predict it in either direction. Screen 4 holds 901 nodes and answers. Screen 7
holds 149 and fails.

A capture taken immediately before each probe held the element every time. So the element was
present and readable while the query for it failed.

Why this is not simply "add the fallback"

Triage notes that #2197 establishes the Simulator snapshot producer and presentation contract
first, and that this work should follow it. We agree, and we want to add one requirement from a
caller's side.

Producer equivalence. A selector resolved through the fallback producer must match identifiers
and labels the same way the primary producer matches them. If the two producers expose different
identifiers, or propagate labels differently, then a query answered from the fallback could report
an element absent when it is present.

For us that would be worse than the failure we reported. A failure stops a flow and names itself. A
false negative passes a check that should have failed, or fails a check that should have passed, and
neither names the producer.

We cannot measure that equivalence ourselves. We tried. We captured one screen twice in one
run, once clean and once degraded, and the two captures turned out to be different states of the
screen rather than one state read two ways. So we have no data on how the two producers differ, and
we are not claiming any.

Acceptance tests we would find convincing

• An element that is present is never reported absent, on either producer, for identifier and label
  selectors alike.
• A true negative is reported identically by both producers, and with the same error code.
• A screen that forces the fallback answers the same selector query as the same screen before it
  degraded.

What would unblock us sooner

Nothing here is urgent for us if #2273 lands. A typed reason that separates "the query could not
run" from "the element is absent" lets a flow retry or read the screen instead, which is enough to
work around this. The fallback is the better fix and the slower one.