perf(flows): wait for the launched app to draw instead of sleeping 1.5s

[filip131311]

What

Every launch: step slept a flat POST_LAUNCH_SETTLE_MS (1500ms) before the run's first step, to give a cold start a head start. restart-app already waits for the activity to be displayed (am start -W), so on any app that is already drawing, that whole window was dead time.

The condition the sleep approximated is observable — the flow's own tree source either shows the app's content or it doesn't. This polls it instead, keeping the same 1500ms as an upper bound: a warm app continues after one read, a genuinely slow start still gets the full window.

What "has drawn" means, and why it isn't just "the tree is non-empty"

Measured on a cold start (Pixel 9 emulator, API 35): a launching Android activity reports a tree of exactly one view for the whole settle window —

count=2 leaves=[{"role":"FrameLayout","identifier":"android:id/content","children":[]}]

— the window's own content frame, with an identifier and nothing else. A "non-empty tree" check would call that blank screen ready. Once the app draws, that shell collapses into real content (the same screen reports 24–53 nodes carrying labels).

So the predicate is addressability, not size: one leaf carrying a label or value is enough. That deliberately includes the case of an app whose entire first screen is a single labelled view — it settles as fast as a dense one, where a plain node-count threshold would have held it for the full budget. The node-count arm (>= 3, i.e. the root plus two views) remains only as a fallback for a screen that draws real content with no labels at all — icons without a content description, a canvas.

Why it can't regress a passing flow

The wait is forgiving in the same places the sleep was silent:

• a tree that never satisfies the predicate spends the whole budget and carries on, exactly as before;
• a tree read that throws is treated the same way;
• treeSourceGate still runs first and is still what reports an unusable tree source. This is a head start, not a gate.

The gate now runs before the head start rather than after it — reading the tree needs the source to be up, and the gate never depended on the sleep. The poll interval is deliberately unhurried (250ms): a hierarchy read is served by the inspected app's own UI thread, which during a cold start is the thing being waited on.

Measurements

Android emulator (Pixel 9, API 35), 6-step flow against a fast app. Runs interleaved with the released build, alternating arm by arm, because host load on the measuring machine drifts enough to swamp a sequential A/B:

run	baseline (1500ms sleep)	this change
1	6.72s	5.27s
2	6.79s	5.39s
3	6.68s	5.07s

~1.45s saved per launch — the sleep minus the ~50–100ms the first tree read costs. The saving is per launch: step, so a flow that relaunches several times saves a multiple of it. iOS gets the same by construction.

Discovered while profiling why an Android flow run costs ~2.5s more than the equivalent agent-device replay on the same device and app; this was the larger of the two fixed overheads. The other is #777.

Testing

• New packages/tool-server/test/flows/flow-launch-settle.test.ts, five cases: continues after a single read once content is present; keeps waiting on an empty tree; keeps waiting on the real android:id/content shell captured above; continues early for a single-labelled-view screen; survives a throwing tree read. The fast-path assertions are on poll count rather than elapsed time, so they don't move with host load.
• vitest run test/flows — 1047 pass. One unrelated failure, flow-idle-run > settles inside the smallest timeout the parser allows, is a wall-clock assertion that fails identically on pristine origin/main (1052ms vs its <1000ms bound) on this loaded machine.
• npm run lint, npm run knip, prettier --check clean.
• Live-verified on the emulator: 7/7 steps on the real app flow, 6/6 on the micro-benchmark.