flaky e2e_ui: test_scheduled_task_create_edit_modal_and_time_picker times out clicking a minute cell

[webdevtodayjason]

tests/e2e_ui/scheduled/test_scheduled_tasks_page.py::test_scheduled_task_create_edit_modal_and_time_picker[chromium] failed the same way on two unrelated PRs today (2026-07-24):

• PR fix(#509): default new-session workspace from selected agent's cwd #580 — E2E UI shard 1/3 (PR touches session-workspace defaulting)
• PR fix(#548): friendly missing-dependency banner with copyable install command #570 — E2E UI shard 2/3 (PR touches the missing-dependency banner)

Failure is identical in both:

page.get_by_test_id("schedule-minute-37").click(force=True)
playwright._impl._errors.TimeoutError: Locator.click: Timeout 30000ms exceeded.

and it comes right after expect(page.get_by_test_id("schedule-minute-37")).to_be_visible() passed on the same locator — so the cell renders, then the click on the minute-wheel column stalls (scroll/snap animation race?). Neither PR goes anywhere near the scheduled-tasks UI, and the test carries no @pytest.mark.flaky rerun marker, so a single race fails the whole shard.

Happy to take a fix if a maintainer confirms the direction (e.g. wait for the wheel's scroll-settle before clicking, or give the test the same flaky(reruns=2) treatment its siblings use).

[webdevtodayjason]

Third occurrence today, third different PR: #700 — E2E UI shard 1/3, identical signature (schedule-minute-37 click(force=True) timeout right after the visibility assertion passed on the same locator). That's 3 of the last ~6 e2e_ui runs across unrelated PRs on my fork alone. Taking a shot at a proper fix (wait for the wheel to settle rather than force-clicking mid-snap) — PR shortly unless someone's already on it.

[webdevtodayjason]

Fourth occurrence today, now on a fourth PR run — #583 E2E UI shard 1/3. Slightly different signature this time: Locator.click: Element is not visible at the same schedule-minute-37 click (vs the 30s timeout in the other three), which smells like the same race caught at a different phase — the cell is present but the wheel/popover is mid-transition when the click resolves. Repro + fix in progress as mentioned above.

[webdevtodayjason]

Fifth hit today (#700 shard 1/3, same 30s click timeout). Fix is ready and measured (11/15 failing → 35/35 green locally; root cause: the assertions race the popover's 150 ms exit animation — the picker is actually closed the whole time because the time input's onFocus opened it early and pointerdown-outside dismissed it). PR incoming as soon as GitHub's PR-create API stops 500ing on my account; branch is pushed at webdevtodayjason/omnigent@df90285b if any maintainer wants it sooner.