scheduler: settled tails defer while their instance is not host-enterable

[lannbot]

scheduler: settled tails defer while their instance is not host-enterable

Fixes #156 — the resumeWith half of the window #155 fixed for tick. Design and reachability analysis: the investigation comment on #156. Adjacent finding filed as #160.

The bug

Store.serviceSettled dispatched every settled activation tail through Thread.resumeWith, which re-establishes the reentrance bracket and asserted inst.mayEnterFrom(null) first. Under the shared synthetic root, a host entry into any instance of the graph locks every sibling, so servicing a sibling's tail in that window crashed:

AssertionError: resumeWith: parked thread's instance is not enterable from the host

Worse than the wrong error channel: resumeWith mutates before asserting (deletes from store.awaiting, flips state), so the assert also stranded the thread and lost the settle. Confirmed reachable on main (jspi mode only), two ways:

• the held async-dtor bracket — callDtorGated's hold-until-settle (resources: own-drop dtor bypasses may_enter gating and trap-poisoning; JS-initiated drops skip the promising entry #85, pinned) is the runtime's one enterFrom(null) that spans an await, a macro-time window during which any sibling settle serviced by the settlement pump or an export call's driveAsync fired the assert;
• nested synchronous driving — a dispatched tail's guest segment runs synchronously to its first Suspending call, and a host import's body reaching an embedder stream op re-enters serviceSettled through HostActivity.pump while the first tail's bracket is open.

driveAsync's race-winner path calls resumeWith directly and had the same exposure.

The fix

A tail whose instance is neither poisoned nor host-enterable is deferred in place — left in the queue, skipped by dispatch — until the lock releases. The property that makes this safe:

the deferral predicate !inst.mayEnterFrom(null) is exactly tick's candidate-filter predicate (#155) on the same instance, so tick can never resume a thread of an instance whose tail is deferred — the phantom-state gate the queue exists for is preserved per-instance by construction.

Per-instance settle order is unchanged; cross-instance order relaxes only when enterability defers a tail, which is conforming schedule nondeterminism (in the reference the tail runs atomically inside the entered bracket, so a host entry admitted during a park necessarily orders before that activation's tail). Poisoned tails still dispatch: resumeWith's poison early-return retires them, and a poisoned leaf never unlocks, so deferring them would leak.

Mechanics:

• Store.serviceSettled: scan-from-head loop — stale entries (thread resumed elsewhere) removed on sight; first dispatchable tail spliced out and dispatched, then rescan (dispatch runs guest code synchronously and can re-enter this function); deferred entries stay in place. Shared predicate: dispatchableTail.
• Store.tick: the settled gate becomes hasServiceableSettled() — a deferred-only queue must not wedge the store (its instances are self-excluded from candidates by the same predicate).
• driveAsync: the two settled.length reads become serviceable-checks (a deferred-only queue otherwise hot-spins the loop — no await in the cycle); both awaiting races exclude threads whose tails the queue owns (their memoized tagAwait tag is already settled — racing them re-wins instantly, an unbounded microtask chain that starves the very host-call settle that would release the lock); the all-deferred case parks on pendingHostCalls, which provably contains the lock-holder's own entry (the dtor bracket registers there; synchronous brackets cannot span the loop's await); the race-winner site gets the dispatch guard.
• The unreachable wedge states (all-deferred with no outstanding host call) stay loud — both the servicing race and the deadlock-probe path fall through to a named deadlock trap instead of busy-idling.
• Thread.resumeWith's assert stays, documented as the internal backstop.

Liveness

Every deferred tail's lock-holder is either a synchronous extent (re-checked when the enclosing serviceSettled iteration or the next driver turn runs) or the async-dtor bracket, whose release edge is a pendingHostCalls settle every driver already races — and callDtorGated registers its leaveTo continuation before inserting the promise, so per-promise FIFO delivers the unlock before any driver's race continuation observes the settle.

Tests

• task_test.ts (synthetic-root section): defer-then-service across a held host entry; the phantom-state gate still refuses tick for a serviceable tail; poisoned tails retire while locked; stale entries are removed regardless of enterability.
• settled_deferral_test.ts (driver-level): B's tail queued, A's host entry held, unlock arriving via a pendingHostCalls settle from a setTimeout(0) — mirrors the dtor bracket's shape; pins park-not-spin, the race-set exclusion, and the all-deferred fallthrough. New shapes verified to fail (assert or stall) on the unfixed runtime.

Gates

just gates — full pass. Conformance: 1416 commands, 1257 passed, 0 failed, no expectation changes; sched-seeds clean (the relaxed tick gate produced zero schedule deltas). No published-surface change, so the lockstep version is left alone per AGENTS.md.