adopt CM#705/#707 cancellation delivery: subtask.cancel rewrite + pending-cancel ASAP bookkeeping

[lannbot]

The CM pin advance (polyengine#173) pulls three upstream cancellation-delivery changes that polyengine's task core predates. They form one coherent adoption track (xfail class cm707-cancel until this issue closes):

1. CM#705's canon_subtask_cancel rewrite (part of the may_enter removal commit, but additive): trap_if(subtask.in_waitable_set() and not async_) strengthens to an unconditional trap; the sync-wait path becomes subtask.has_sync_waiter = True + thread.wait_until(subtask.resolved) (replacing wait_for_pending_event). Our implementation of the pinned conditional form is runtime/src/intrinsics/async_builtins.ts (st.inWaitableSet() && !async_); hasSyncWaiter already exists on waitables for the stream paths.
2. CM#707 — deliver cancellation as soon as possible: pending-cancel bookkeeping must (a) NOT deliver at non-cancellable suspension points (thread.yield nc returns 0, request stays pending), (b) deliver at the next cancellable suspension, and (c) deliver when the callee's exclusive lock frees, even if the parked task's waitable set never fires.
3. 6c67aa1 — deliver_pending_cancellation ordering fix (moved before stop_waiting_internal): verify our delivery site ordering against the merged definitions.py.

Corpus rows pinning the merged behavior:

• test/async/cancel-and-exclusive-lock.wast (new, CM#707): subtask.cancel async on a callee whose lock is held returns BLOCKED and stores the request pending; delivery happens on lock release (TASK_CANCELLED → task.cancel → CANCELLED_BEFORE_RETURNED). A pre-#707 runtime hangs.
• test/async/cancellable.wast (extended, CM#707): Test 5 pending-survives-nc-yield — single final assert covers all five tests, so the file fails wholesale until the nc-yield distinction exists.
• test/async/trap-if-block-and-sync.wast (rewritten): the trap-if-sync-cancel case now requires real attempt-delivery-then-trap-on-block behavior; the four {stream,future}.cancel-{read,write} sync-trap directives are deleted upstream (guest-guest cancels never block under #707).
• test/async/reentrance.wast case 9 also exercises immediate delivery with the callee on stack, but is xfailed under fact-reentrance-47 regardless (see the wasmtime-bump register issue).

Adjacent: #212 (trapping cancellation delivery poisons via the settled-tail path) — same territory; re-derive its parity question against the merged definitions.py while in there. The may_enter gate in Task.requestCancellation is removed by the #173 gate-removal PR, not this track.

Authority: design/mvp/canonical-abi/definitions.py at the advanced pin (tie-breaker). Task core is single-owner territory (AGENTS.md): coder-hard at most, close orchestrator review.

[lannbot]

Hold this track: upstream is rewriting the semantics it targets. component-model#716 (open, lukewagner) deletes most of what item 2 here plans to build. Re-derivation below; recommendation at the end.

What CM#716 does (vs our pin 2f13265)

1. cancellable is removed from the thread.*/waitable-set.* built-ins — text format drops the immediate; the binary immediate becomes a reserved byte that must be 0x00 (new assert_malformed coverage; note upstream adds binary.wast to its own nyi.txt because current wasmtime doesn't enforce this yet). Rationale: no producer emits it, and the single 1 return conflated cancelled-before-switch / resumed-because-cancelled / cancelled-after-readied. It may return in a different design when the stackful ABI (🚟) needs it. The whole Cancelled enum + Thread.resume(cancelled) + cancellable() predicate plumbing disappears from definitions.py.
2. Task.request_cancellation stops delivering by resuming candidate threads. STARTED state: the request just parks as PENDING_CANCEL, full stop. Delivery happens only at designated points in the callee's own execution: the task-entry backpressure wait, the callback event-loop turn (deliver_pending_cancel() at turn start), and the new WaitableSet.wait_from_callback (whose ready condition is exclusive_thread is None and (has_pending_event or has_pending_cancel)). A stackful task parked on plain waitable-set.wait simply never observes cancellation mid-wait — coherent with "nobody emits cancellable". INITIAL state: park pending + implicit_thread.resume(), which runs the entry, delivers at the backpressure wait, and resolves CANCELLED_BEFORE_STARTED synchronously (the new assert(state == RESOLVED)).
3. canon_subtask_cancel's async form does a plain thread.yield_() instead of the at-most-1-switch caller→callee→caller discipline — the host may schedule anyone before BLOCKED is determined. The parts this issue already lists from CM#705 survive intact: the unconditional trap_if(subtask.in_waitable_set()) and the sync path's has_sync_waiter + wait_until(subtask.resolved).
4. Tests: cancellable.wast deleted (including the Test-5 nc-yield pin this issue cites); cancel-delivery.wast is new; cancel-and-exclusive-lock.wast keeps its pending-delivery-on-lock-free behavior with reworded rationale; reentrance.wast case 9 is rewritten so the reentrant async cancel deterministically reports BLOCKED (delivery via the callee's event loop, which the pinned sync stack makes unreachable).

Impact on this issue's scope

• Item 2 (#707 cancellable-point bookkeeping — deliver at next cancellable suspension, survive nc-yield) is dead machinery walking. Building it against pin 2f13265 would be exactly the pin-advance migration map: CM#705 removes the may_enter flag/trap #173 lesson: investment in machinery with an upstream expiry date. Its corpus pin (cancellable.wast Test 5) is deleted by #716 — and polyengine currently passes that file anyway.
• Item 1 (subtask.cancel rewrite) survives but gains the async-yield relaxation, which is friendlier to our driver model (schedule freedom instead of a forced switch pattern).
• Item 3 (6c67aa1 ordering) is subsumed: deliver_pending_cancel call sites are restructured wholesale.
• The one live corpus xfail (cancel-and-exclusive-lock.wast:196, class cm707-cancel) pins behavior that survives #716 — pending request delivered when the exclusive lock frees even if the waiter's own ready condition never fires — so the class and this issue remain real work, in smaller clothes.
• Side effect worth recording: post-#716, request_cancellation never resumes a thread, so jspi: a trapping cancellation delivery poisons via the settled-tail path, not synchronously in requestCancellation — intermediate-window parity unproven #212's premise (a trapping cancellation delivery inside requestCancellation) mostly evaporates — delivery traps become ordinary callee-side traps at its own designated points. Re-derive jspi: a trapping cancellation delivery poisons via the settled-tail path, not synchronously in requestCancellation — intermediate-window parity unproven #212 whenever this lands.
• polyengine's existing mirrors of the deleted machinery (Cancelled/CANCELLED_TRUE, waitUntil(ready, cancellable), Thread.cancellable, requestCancellation's candidate scan) go on the deletion list at the pin advance that includes #716 — nothing is removed preemptively (docs/architecture.md §1 discipline; the pinned reference remains the tie-breaker until then).

Recommendation

Block this issue on CM#716 (label: upstream-tracking). No implementation against the 2f13265 cancellation form. When #716 merges: advance the pin (routine re-triage: reentrance.wast renumbering shifts the fact-reentrance-47 xfail lines; the new binary.wast must-be-0 rows join the wasmparser-47 drift in #248; cancellable.wast's rows vanish), then implement the post-#716 form in one pass: subtask.cancel (unconditional trap + sync has_sync_waiter wait + async yield), pending-only request_cancellation with designated delivery points, and the callback event-loop wait_from_callback shape.