axbridge: asserted marker tap resolves the label before the assertion, so a same-labelled container wins over the matching Key #988

With the axbridge backend, a marker tap that carries an assertion picks its target by label alone and checks the assertion afterwards. If an element earlier in tree order has the same label, the assertion refuses it and the element that actually satisfies the assertion is never considered.

Shape where this shows up: an OTP-style input whose accessibility label collapses to the single digit just typed, with the software keyboard up.

idb ui tap 7 --api axbridge --expected-key role --expected-value Key

fails with

The axbridge backend expected role to equal "Key" before tapping, but it was "RCTViewComponentView"

even though a framed keyboard Key labelled 7 is in the same tree. A distinct same-labelled text field earlier in the tree behaves the same way. Two Keys with the same label resolve silently to the first one rather than being reported as ambiguous.

On main (6079df9f) this comes from AXBridgeTreeReader.writeTarget calling markerTarget and only then validate(callerAssertion, against:) (FBSimulatorAX/AXBridge/AXWriteTarget.swift), with AXTreeWalk.preferredMatch returning the first exact label match regardless of role. The guest-side check at dispatch also compares only the searched key, so a same-labelled element with a different role at the tap point passes it.

A fix along these lines:

• When the caller passes an assertion, filter candidates through it inside preferredMatch's existing resolve: hook, keep exact-before-containing tiers, and refuse more than one framed match in the winning tier with a new ambiguity error. Missing, off-screen and mismatch keep their current errors.
• Send the selected node's raw automationType/elementType (whichever role(of:) used) as an extra guest-checked assertion alongside the label, as one optional field on BridgeAXWriteRequest that encodes to nothing when nil.
• Unasserted marker writes keep first-match selection and byte-identical requests.

With that, the host, protocol and control unit suites and the full SimulatorFrameworkBridgeLibTests scheme pass, and new regressions for the container, text-field and duplicate-Key cases fail before the change and pass after. A different Key with the same label and role at the same point still can't be told apart, since element identity isn't on the structural read. The change is about 110 lines of source plus tests.