Support multiple testWidgets with shared app binding in integration_test (flutter drive mode)

### Use case

I am running integration tests using integration_test with flutter drive.
On Web, the app starts once. The first testWidgets executes successfully, finding widgets and interacting with the app.
However, when the first test finishes and the second testWidgets (in the same file) starts:
The framework creates a new WidgetTester.
This new tester is not attached to the app's widget tree (which is still running in the browser/device).
As a result, find.byType(...) returns empty, and context-dependent logic (like Get.context or Navigator lookups) fails because the tester "sees" an empty tree.

Current behavior:
The binding/element tree connection seems to be torn down after the first test, leaving subsequent tests in the same run unable to interact with the running app.

### Proposal

Desired behavior:
When running via flutter drive (where the app process persists), integration_test should allow multiple testWidgets to execute in sequence against the same running app instance, maintaining the binding/connection so that the second test can continue where the first left off (or after a manual reset), or after a manual reset (navigate to / ) starts a whole new test inside the same group.

Use case:
This is critical for scalability. We want to run multiple independent scenarios (or a sequence of flows like "Login" -> "Reset" -> "Login again") in a single test file without restarting the app process for every single test case, which is very slow. Running on m1 pro it takes 70 seconds to start everything and just then start the test.

Workarounds tried:
Combining everything into a single huge testWidgets (works but monolithic and hard to manage).
Running one test file per scenario (works but requires restarting the app for every file ~ 70 seconds of delay per run).