fix(performance): the widget tree never reaches an idle frame, so pumpAndSettle times out

[koniz-dev]

Context

On a real Android emulator, await $.pumpAndSettle() immediately after booting
the app throws:

pumpAndSettle timed out
#0  WidgetTester.pumpAndSettle.<anonymous closure> (widget_tester.dart:717:11)
#3  main.<anonymous closure> (integration_test/app_e2e_test.dart:29:5)

Evidence: run 32975097312.
The test spent 131s before failing, and the app itself boots fine - so this is
not a crash. pumpAndSettle waits for a frame in which nothing is scheduled, and
this tree apparently never produces one.

The E2E tests have been changed to use waitUntilVisible instead (#33), which
polls rather than demanding quiescence. That unblocks E2E but does not answer
why, and the answer matters:

• Anyone writing a widget test against the full app via
  test/helpers/pump_app.dart will hit the same wall the moment they call
  pumpAndSettle on the real widget tree rather than a single screen.
• A tree that always has work scheduled means the framework is producing frames
  continuously. On a real device that is battery and jank, not just a test
  problem.

Already ruled out by reading the source

Do not re-check these:

• No spinner on the initial route. AuthState.isLoading is
  @Default(false), so login_screen.dart:104 renders text, not a
  CircularProgressIndicator.
• No AnimationController anywhere in lib/.
• No repeating timer. The only Timer( in lib/core/ is
  utils/debouncer.dart:38, one-shot.
• No startup network call. authNotifierProvider.build() returns
  const AuthState(); getCurrentUser() is not called on build.
• .env absence is not it. EnvConfig.load() swallows every exception.

Where to look next

• flutter_native_splash and whatever keeps the native splash alive after first
  frame.
• lib/core/performance/ - the no-op performance service and its screen mixin
  (performance_screen_mixin.dart) hook frame callbacks.
• NavigationLoggingObserver on the router.
• lib/shared/widgets/optimized_image.dart and the image cache warm-up in
  main().

flutter run --profile plus the DevTools frame chart on a device will show what
is scheduling frames, in a way static reading cannot.

Acceptance criteria

1. The cause is named concretely: which widget, mixin, or plugin schedules a
   frame every tick. A reference to the specific file and line, not a hypothesis.
2. Either the continuous scheduling is removed, or it is documented as
   intentional with the reason and the cost.
3. A widget test that pumps the full app (not a single screen) and calls
   pumpAndSettle() completes without timing out - or, if the scheduling is
   intentional, test/helpers/pump_app.dart gains a doc comment saying
   pumpAndSettle must not be used with it and what to use instead.
4. If the cause is removed: the E2E tests may return to pumpAndSettle, but only
   with a dispatched E2E run proving it. Do not revert fix(testing): the shipped E2E test cannot pass without a backend, so every fork inherits a red run #33 on reasoning alone.
5. ./scripts/dev/audit_template.sh exits 0.

[koniz-dev]

Setting status:blocked: GitHub Actions is not assigning runners for this repo, so the acceptance criteria cannot be verified.

State right now:

• Coverage Analysis dispatch concluded failure at run level with its only job still queued and no steps executed.
• gh run rerun was accepted; the run returned to queued and stayed there.
• An E2E Android (Patrol) run has been queued since 15:25Z with nothing else occupying runners.
• The last run that actually executed was 14:42Z.
• All eight workflows report state: active.

To unblock: nothing in this repository. Once Actions schedules runners again, re-dispatch and the remaining criteria can be checked. No code decision is pending.

[koniz-dev]

Investigation is partly done; the decisive experiment is the queued run.

Ruled out so far, by reading source rather than guessing: no spinner on the initial route (isLoading defaults false), no AnimationController and no Timer.periodic outside Debouncer in lib/, no startup network call, .env absence is swallowed.

New finding: a host-VM probe using LiveTestWidgetsFlutterBinding settled under BOTH fadePointers and onlyPumps, so the host cannot reproduce this - there is no real vsync. That rules out a pure app-tree explanation reproducible off-device.

Strong but unproven hypothesis: PatrolBinding extends LiveTestWidgetsFlutterBinding (patrol 3.20.0 lib/src/binding.dart:43), whose framePolicy defaults to fadePointers (flutter_test binding.dart:2755), which draws a frame whenever _viewNeedsPaint (line 2798). Flutter's own docs say any policy other than onlyPumps "results in pumping extra frames".

A binary experiment is committed on branch investigate/frame-policy-probe (integration_test/frame_policy_probe_test.dart): the same pumpAndSettle under both policies. onlyPumps settles + fadePointers times out proves the binding; both timing out proves the app. Run 32985078313 is that experiment, and it has been queued since 15:25Z.

I am not closing this on the hypothesis - criterion 1 asks for a concrete cause, not a plausible one.