Runner: per-case execution budget and timeout (limit-exceeded provenance)

[lann]

The runner has no defense against hanging cases: one wedged case hangs the whole run (at --jobs 8, a worker) until the CI job limit kills everything with zero attribution. The no-retries policy makes a guard the only defense. Design settled in discussion; recording here.

Two budgets for two hang classes (each enforceable only where its class manifests):

• --case-execution-budget <secs> (default 10, 0 disables): budget on actual wasm execution, approximated as epoch ticks observed by Store::epoch_deadline_callback (the callback only fires while wasm executes and missed ticks collapse on resume, so preemption under-counts — contention-robust, ~thread time). Catches CPU spins, where a host-side timer is useless because the executor thread is stuck inside wasm. Trips as a distinguishable error through the normal trap plumbing.
• --case-timeout <secs> (default 120, 0 disables): wall clock from case start, enforced by racing the run future against a timer. Catches async wedges (pending().await, wedged stream reads — the findings-wasi:cli runner #3 class), where the epoch callback is useless because no wasm executes. Scheduled-time exclusion (wake→poll latency) deliberately omitted: one case per worker executor today makes it ~zero; revisit with Future: additive concurrent-tests interface (concurrent runs + streaming enumeration) #20.

Containment = the existing trap path: mark the case failed, abandon the session (store drop unwinds suspended fibers safely), fresh session next case. Both --jobs paths via a shared per-case helper (extracting it first — the sequential/parallel copy-paste divergence from #43).

Wire form: Provenance::HangGuard (reserved, never emitted) is renamed in its last safe window to limit-exceeded(string) — externally tagged, so unit provenances stay flat strings and this one serializes as {"limit-exceeded":"execution-budget"} / {"limit-exceeded":"case-timeout"}, leaving room for future limits (memory, fuel) as payload vocabulary rather than schema change. Status fail, one-line detail with the configured value, diagnostics-complete: false, fold's not-reached cause-attribution updated to match.

Enumeration is guarded too (a wedged registry constructor): trips there are run errors (exit 2), not case results.

Fixture: components/hang-fixture (broken by design): hang/spin (loop {} — epoch path), hang/pend (std::future::pending().await — timer path), hang/after (containment). Gated tests run it at 1s/2s budgets.

Out of scope: composed runner (it is the wasm; its guard is the outer wasmtime invocation) and jco/Node (can't preempt wasm). Follow-up issue covers context.progress keepalive + --hard-timeout (requires a wit/tests.wit growth-channel investigation: @since gates vs version-linkage across wit-bindgen/jco/wac).

[lann]

Landed as 1aee31b (serve_case extraction, unified session-failure policy) + 9d9dae0 (the budgets). Both implemented per the discussed design with the limit-exceeded(string) provenance from review.

Empirical results worth knowing (now findings #16–18):

• epoch_deadline_callback composes with component-model-async, and its Err survives downcast through the trap unwind — the discrimination needs no Trap-code sniffing.
• in_tokio has timers enabled, so the wall race is just tokio::time::sleep.
• std::future::pending().await does not wedge a wit-bindgen 0.60 guest — it traps (the runtime refuses to park on Rust-originating-only events without the inter-task-wakeup feature). A genuine wedge must wait on the host; hang/wedge uses a WASI sleep.

Defaults: execution budget 10s, case timeout 120s, 0 disables either. Enumeration is guarded as a run error. hang-fixture pins both classes + containment at 1s/2s budgets; a second gated test pins that disabled budgets + --jobs are byte-identical to baseline. Out of scope as discussed: composed/jco topologies (can't preempt wasm from inside).

[lann]

Post-landing correction (6cb88ad): the tick-counting implementation was not contention-robust as designed. The "missed ticks collapse on resume" property only engages when a store executes no wasm for a whole tick interval — true for blocked/suspended stores (the async-wedge class), false for CPU-bound cases under scheduler time-slicing: the thread is runnable throughout, executes inside essentially every 100ms wall window, and observes essentially every tick, so tick counts degenerate to wall time exactly when the machine is contended. First hit downstream as polymorph-components/polymorph-webcrypto#322's CI failure (honest high-iteration PBKDF2 running in-guest, 8 jobs on 4 vCPU), reproduced deterministically under taskset -c 0,1.

Fixed by keeping the epoch callback as the sampling hook (still the only way to regain control from a spin) but charging the executing thread's CPU clock (CLOCK_THREAD_CPUTIME_ID) between consecutive same-thread samples — sound because both runner paths poll each store on a dedicated OS thread; thread changes re-baseline; non-unix falls back to tick-per-callback. The previously-failing scenario now runs clean at the 10s default under the same constraint; hang-fixture still catches both classes.