0.0.15

Fixed

• A dusk:observe candidate could not be told apart from another carrying the same label, so acting on one moved the other. Every handle observe minted carried the semantics label alone (ext_observe.dart), so N candidates sharing a label got N handles that all re-resolved to the first match, which contradicts the one-candidate-per-interactive-node contract the tool documents. It costs a real session: an agent that correctly picked the third row of a list by its bounds tapped the first, and both calls reported success. A consumer spent two releases recording an app defect that was this, with a viewport sweep and six eliminations behind it, because moving the viewport moved the wrong control in and out of a bottom bar's way. DuskQuery gains matchIndex, the node's position among every node whose label matched, in walk order. Observe counts it on SemanticsNode.label rather than on getSemanticsData().label, which are different strings under merged semantics (semantics.dart:3801-3804 concatenates every merged descendant's label into the data), and before its role filter and before its interactivity check, so the resolver's walk and its own count the same universe. An index that stops resolving reports no match rather than falling back to a surviving namesake; an index is a POSITION and not an identity, so a row inserted above a list after the observe call shifts every held handle with no staleness signal, which the docs now say. dusk:find is unchanged: a predicate a caller chose keeps answering the first match and reporting the total. (lib/src/ref_registry.dart, lib/src/extensions/ext_observe.dart, lib/src/extensions/ext_find.dart)