ultraflow: two-stage classify, eager pauses, and context-menu/download operations to beat jev-ultrafast #617

Head-to-head evidence from 2026-10-04 (pixel ultraflow vs browser-use/jev-ultrafast on the same Google Drive task, run live):

• pixel discover blocked in 36.7s: 64-label Ollaya budget truncated the action space, the model clicked a filter chip at p=0.21 then answered BLOCKED; the offered/truncated counts were invisible in the human log.
• jev blocked too (4.0s): search executed fine, but the results page stalled it. Same perception failure class, ~5x faster where the loop works.
• Verified on the real Drive results page with agent-browser: file rows ARE exposed (link "Notion Invoice January 12, 2025.pdf" [ref=e81]), the download path is a context menu (Download as an ordinary menuitem), and Advanced search is a deterministic form front door.

Work plan (each its own PR on top of main):

1. Two-stage classify: operation first (7 options), then target among only that operation's slots - kills the 64-label ceiling while keeping every decision classified, never generated.
2. Eager pause policy: poll url/changed_since instead of the fixed 3s open + 2s click sleeps in pixel-flow execute.
3. contextmenu operation + download flow step with on-disk verification (Jev structurally cannot do either).
4. Discovery honesty: print offered/truncated in render_trace, disclose the label-budget cut in the elements table, do not cancel remaining --repeat runs on a model-chosen BLOCKED.
5. Perception completion: scrollIntoView-before-act rule; classify policy guidance for search front doors, filter-chip traps and menu-close behavior.