Fix/wait for at

[dworik]

Fixes issue #1938

Problem

first, last, and at() delegated directly to Flutter finders, which throw immediately for empty results (StateError/RangeError). That prevented Patrol’s normal waiting behavior in tap()/waitUntilVisible() from kicking in when a widget appeared later.

Fix

Replaced those selectors with a Patrol wrapper that returns an empty result instead of throwing when the selected element is not available yet. This lets waitUntilVisible() keep retrying until the widget appears or the regular timeout is reached.

Test plan

• dart analyze in packages/patrol_finders clean
• flutter test in packages/patrol_finders/test - 127/127 passed, including 7 new tests covering:
  • negative numbers
  • widgets appearing after delay
  • non-existing widgets
• patrol test in dev/e2e_app/patrol_test/at_finder_test.dart - successfully waits for a second widget to appear without throwing.

at._demo.mov

CI

• test android emulator webview... expected to fail

[gemini-code-assist]

Code Review

This pull request replaces the standard finder.at(index) with a custom _PatrolIndexFinder implementation, enabling finders to wait for elements at specific indices to appear. Test cases have been updated to reflect that out-of-bounds indices now result in no widgets found rather than throwing an error. A critical bug was identified in the new filter logic where negative indices would cause a crash; it is recommended to handle these by returning early to ensure consistency with positive out-of-range indices.

[pdenert]

Please also add video of the demo run of this tests