fix(lens): group variants by the element label, not the matcher

[filip131311]

Fixes #624.

The bug, and a worse half the issue doesn't mention

Identity was keyed on match (defaulted to {by:"text", value: element}), never on element. Because that default equals the label, calls that omit match accumulate correctly — which is exactly why this stayed hidden.

Reported direction — supplying match forks a second card:

element "QA probe button", no match      → el-qa-probe-button-1
element "QA probe button", match SUBMIT  → el-qa-probe-button-2   ← forked, totalElements: 2

Unreported direction — and this one is worse. The key is symmetric, so two different labels sharing a matcher value merge. Verified deliberately:

element "Header logo",  match {text: SHARED} → el-header-logo-4
element "Footer link",  match {text: SHARED} → el-header-logo-4
                                               and the response came back
                                               element: "Header logo"

I asked to stage a variant for Footer link and it was filed under Header logo, with the response naming the wrong element and nothing indicating another element had absorbed it. A human picker card would show one component's variants under another's name. I hit this by accident first: a fresh "Checkout CTA" call carrying match: {text: SUBMIT} landed on el-qa-probe-button-2.

The fix

Identity is the element label, compared ignoring case and surrounding whitespace — which keeps it coherent with the id slug, that already folds both.

match becomes a locator. A matcher the agent supplies replaces the label-derived default (that default is a synthesized placeholder; a real matcher is strictly better). Two different explicit matchers for one label is ambiguous — the agent may have meant two elements — so the first is kept and the second is reported:

Kept the matcher this element already had (identifier=buy-top) and ignored identifier=buy-bottom
— variants group by the `element` label, so give a different label if these are different elements.

Silently dropping it would have been the same class of bug as the one being fixed.

One UI change was required. index.html locks a card's anchor against the matcher it first resolved and never invalidates it, so an upgraded locator would leave the card homed on the old node. It now re-homes when the matcher changes.

I initially wanted to avoid touching the UI by never mutating the stored matcher — the critique showed that was the wrong trade. A stale anchor yields an unanchored but revealable card (rec.gone is false under revealOffscreen, and there's an explicit off-screen prompt), whereas keeping a fuzzy first matcher leaves a card confidently pointing at the wrong element forever. And the UI ships inside the tool-server bundle, so there's no version skew to avoid.

Variant ids are now per-element. They came from a store-wide counter while variantCount was per-proposal, so an element's second variant could be called v5 — that mismatch is how the reporter first noticed something was wrong. Safe: reset() already zeroed the counter each round, so store-wide uniqueness was never a property anything could rely on, and every consumer (store lookups, buildOutcome, the UI staged map, drag payload, submit) is elementId-scoped.

Verified live

sequence	result
the issue's three calls	one card, totalElements: 1, counts 1 → 2 → 3
two labels sharing a matcher	two cards, each response naming its own element
conflicting explicit matchers	first kept, second reported in the hint

Known consequence

Two genuinely different elements that share a label now merge — nothing forced distinct labels before. That's the flip side of making the label the identity, it's what the docs already promised, and the hint names the remedy when it's detectable. SKILL.md now states the label is the identity.

Checks

• 3092 tests pass. 6 new, all 6 failing against the pre-fix source; the 54 existing variant tests pass unmodified.
• Telemetry note: element_count per round will read lower where labels previously forked, so pre/post Lens funnel numbers aren't strictly comparable.
• Behind the argent-lens flag. Skills gate 10.0; extract-tools 46/46; prettier, eslint, both typechecks clean; lock untouched.