fix(flow): refuse a recorded tap that would replay somewhere else

[hubgan]

Stacked on #721.

The core mismatch

Replay taps a selector's centre, not the point that was recorded. The recorder only checked that the resolved frame contained the point — which lets two silent misfires through.

1. Container-sized targets

A tap on blank space inside a drawer resolved to the drawer's whole scroll area — 0.72 of the screen. It contains the point, so it recorded. Replay then tapped its centre, hit the "Chat" item, and reported pass while navigating somewhere the walkthrough never went.

A frame covering most of the screen is a container, not a control, and is now refused with that reason. Narrowing cannot help here: the problem is the element, not the selector.

The threshold is a judgement between two real failures. Too permissive records containers (above); too strict makes ordinary widgets unrecordable — a feed post is half the screen and tapping it is a perfectly normal QA step.

Why not "does the centre resolve back to the same node"? That test was tried and is wrong on a flattened tree: a control's own label is a sibling rect sitting on its centre, so a like button, a search field, a full-width row and every grid cell were refused — while replaying perfectly, because the touch is still inside the control. Node identity cannot tell a label from an independent control; size can tell a control from a container.

2. Ambiguity is answered by narrowing, not coordinates

When the derived selector matches the tapped element and something else and ranks the other first, the recorder now tries narrower forms — the node's own role, then its identifier — before giving up. The runner resolves either form, so answering ambiguity with coordinates was throwing away a perfectly good target.

A within scope is deliberately not derived, even though it would separate one feed row's button from another's. The flow tree is flattened and carries no z-order, so a container can only be found geometrically — and with a modal open, the foreground modal is a perfectly good geometric ancestor of a background element. A tap on a composer's text input recorded as a feed post "inside" the composer, then failed on any screen whose feed content differed. The scopes that survive are the ones an author writes knowingly at polish.

3. Positional ids are no longer derived

profilePager-selector-2 encodes the element's index among its siblings, so it names a slot rather than a thing: it survives no re-order and silently addresses a different control once one is inserted before it.

It matters most where the recorder is least reliable. Observed on an edit-profile sheet: a tap on the display-name field derived the profile pager's "Media" tab — a view behind the modal. An oversized or ambiguous background match is caught by the two checks above; a positional id passes all of them and records silently.

4. Every kept-coordinate warning names the retarget

A coordinate tap replays fine today and breaks on the first layout change, so this warning is the author's only signal — and it is read at the one moment the screen is still there to retarget against.

The two failures need opposite advice: an element nothing can address needs a real target found in the tree; one that several things address equally needs disambiguating. Saying "no selector could be derived" for the second sent authors off to re-discover a selector they already had.

Raw-coordinate steps where capture never ran at all — delayMs set, gesture-custom, taps buried inside a run-sequence — now say why the rewrite was skipped and how to record it so that it happens.