Manual comparison with the repository's real-app e2e driver.

Apply replay-seed.patch to the runner checkout. This selects the public replay fixture that waits for user input, making Stop generation deterministic. No live provider is used.
Place scheduled-run-stop.e2e.ts in scripts/scenarios/.
Install each app checkout with vp i.
From the runner checkout's scripts directory, run once per app commit:
T3CODE_DEV_SEED=0 E2E_TELEMETRY_DISABLED=1 T3_SCENARIO_APP_DIR=<app-checkout> vp exec e2e run scenarios/scheduled-run-stop.e2e.ts --target web --output .e2e/<unique-run-name>

Base: b3fdf2b10fb92e5dbc71a83381c602a8a464bbca
Head: cb5ef5642bc6013dc133a28c338c5ea8a6163cd1

Both use Chromium 156, Linux, light theme, 1280x800, a new server-created database, and the same synthetic project and task.
The same driver creates a new-thread scheduled task, clicks Run now, opens the generated thread, clicks Stop generation while the replay waits for input, waits for Stop to disappear, and returns to Scheduled tasks.
Base visibly reports succeeded without a reason. Head visibly reports failed with The run was interrupted.
Outcome PNGs were unchanged across two captures at least 500ms apart.
Videos show the run and stop interaction through the outcome. Only runtime-selection metadata is masked; statuses, errors, and Stop controls are visible. Videos omit earlier task-creation setup and trailing assertion waits.

AI-assisted; verified with the tests and tools listed above.