Cooperative JavaScript jobs

Return bounded continuations with progress and cancellation inside the JavaScript sandbox.

Bounded guest-returned pending jobs

Original §53 requires Blocks to return pending jobs with automatic queued/loading/running/progress/complete/failed/cancel handling. JavaScript Blocks can now opt into manifest.jobs={kind:'cooperative',version:1} and return job.pending from their sandboxed code. This is an actual guest-returned continuation protocol consumed by the host, not merely a promise around synchronous final outputs.

The opt-in reserves input/state/job arguments. Legacy packages retain their old invocation shape. Each pending return is a strict JSON envelope; continuation data has no authority. The same pinned code and original inputs resume in the same disposable VM for up to 32 turns. CPU time remains cumulative 500 ms across VM evaluations; heap/WASM limits remain 16/32 MiB; serialized continuation, state and final outputs together are bounded by 4 MiB. The host yields between turns but never extends existing browser/Node worker deadlines. Each pending state remains private until a final valid result; cancelled or failed runs publish no intermediate output/state.

Progress contains only validated turn/unit counters. Node and browser worker transports validate ordered continuation messages separately from final results; the host job handle validates them again. Omitted progress shows a pending turn, not guessed completion. The UI labels declared continuation units separately from recipe operations. Terminal cancellation remains one-shot and stops the original worker; it cannot restart an invocation or dispatch a provider. Export archives include the runtime helper, and portable SDK documentation describes the API and bounds.

The visual authoring checkbox enables the protocol; source code defines its actual continuation behavior. Existing preview, connected and import sample surfaces share the resulting status/cancellation UI. External asynchronous jobs, arbitrary polling URLs, timers inside the guest, network permissions, provider dispatch and durable reload recovery are not introduced. Reload durability is not inferred as a requirement from §53.

Source inspection only: no tests, browser QA, verification builds, migrations or provider calls were performed. Implementation was committed locally without push or deployment. Operational/runtime acceptance remains unverified.