fix: prefer topmost route when resolving tap/enter_text by text/key

[ReniDelonzek]

Problem

When a screen is pushed over another that stays mounted (a very common Navigator/Overlay pattern), _findElementByText and _findElementByKey in flutter_skill.dart walk the entire element tree from rootElement and return the first match. In pre-order traversal the background route (mounted first) is visited before the foreground one, so tap(text:) / tap(key:) can hit an element that is invisible, behind the current screen.

Concrete case: a foreground screen has a tab labeled "X" while the background screen (still mounted underneath) also renders "X" as a list subtitle. tap(text: "X") lands on the background occurrence instead of the visible tab.

This is tracked in #52 (Problem 2).

Fix

Collect all matches and return the last one. In Overlay/Navigator order the foreground route is mounted last and therefore visited last, so the last match targets the screen the user actually sees. Minimal, dependency-free, and strictly better than first-match for stacked routes (single-match behavior is unchanged).

Applied to both the canonical lib/flutter_skill.dart and the bundled packaging/npm/dart/lib/flutter_skill.dart.

static Element? _preferTopmostMatch(List<Element> matches) {
  if (matches.isEmpty) return null;
  return matches.last;
}

Follow-ups (not in this PR, see #52)

• A center hit-test per candidate would make the choice exact (skip anything covered by a barrier/route). Noted in the helper's doc comment as a layering point.
• Problem 1 in tap by ref/coordinates rejected by published server; tap(text:) hits background route in stacked screens #52: the published npm server binary rejects tap by ref and by x/y ("Must provide key or text for tap") even though the same-tag source already implements them — looks like the shipped binary lags the source and needs a rebuild/republish.
• Problem 3 in tap by ref/coordinates rejected by published server; tap(text:) hits background route in stacked screens #52: resolve enter_text/tap by Semantics.identifier/label (or nearest descendant EditableText) so wrapped/masked fields without a ValueKey are addressable.

Notes

• Did not run dart format on the touched files: the formatter reflows ~900 lines (repo style differs from default dart format), which would bury the change. The edit follows the surrounding style. Happy to adjust if the project has a specific format step.