Blocking PyScript execution lacks uniform timeout semantics across worker and main-thread modes

A <py-script> that performs CPU-bound work or awaits a slow operation cannot be interrupted uniformly. When execution runs on the browser main thread, a synchronous Python loop freezes the page, and no documented timeout attribute on the tag reliably stops it. Moving execution into a Web Worker via the worker attribute or <py-worker> keeps the UI responsive, but cooperative cancellation still depends on Pyodide's asyncio integration: asyncio.Task.cancel and asyncio.wait_for only take effect at await boundaries and cannot preempt synchronous code.

The behavior is further complicated by runtime differences. Pyodide supports asyncio cancellation for I/O-bound coroutines, whereas MicroPython (<mpy-script>) targets have a smaller standard library and different asyncio/threading support, so timeout code that works under one runtime may not behave identically under the other. There is no single documented timeout or cancellation attribute on <py-script> with consistent semantics across both runtimes, and whether a given release honors any timeout is version-sensitive.

Given these constraints, which execution model provides the most predictable interruption behavior for long-running tasks? Does any current PyScript release expose a documented timeout mechanism for worker-based execution, or must cancellation remain entirely cooperative at await points? How should developers verify that a chosen approach works identically across Pyodide and MicroPython targets without relying on undocumented attributes?