adopt CM#705 sync-call scheduling: exclusive-thread resumability, candidate sets, backpressure STARTING

[lannbot]

CM#705 (merged upstream; migration map polyengine#173) changed the sync-call mini-scheduler's semantics beyond the may_enter removal: the exclusive thread is no longer excluded from the resume candidate set, and callback-task threads parked on the exclusive lock become resumable during a sync call. polyengine's driveSyncLift (runtime/src/task/scheduler.ts) implements the pinned (pre-#705) form — candidates exclude inst.exclusiveThread — and the adjacent backpressure behavior produces pre-#705 subtask codes.

New/changed corpus rows pinning the merged semantics (xfailed under class cm705-sync-sched until this issue closes):

• test/async/during-sync-call-exclusive-resume.wast (new; replaces the deleted during-sync-call-no-exclusive-resume.wast with inverted semantics): a parked callback-task thread holding/waiting on the exclusive lock must be resumable mid-sync-call.
• test/async/during-sync-scheduling-candidates.wast (new, 484 lines): candidate-set membership per thread kind; §3 (parked callback-task threads, incl. driven from a sibling), §4 (callback thread blocked mid-frame holding the lock), §5 (sync-lifted async-typed function's thread blocked mid-frame) expect resumability the current scheduler refuses.
• test/async/during-sync-call-may-block-if-other-ready-threads.wast (rewritten): appended third component needs mid-sync-call resumption of a parked callback-task thread.
• test/async/during-sync-call-no-sibling-resume.wast: the pinned rule (only same-instance threads) is unchanged, but the expected trap is now "cannot block a synchronous task before returning" where we produce the deadlock message — verify/align the trap site.
• test/async/sync-streams.wast (changed by the #705 commit): an async-lowered call into a callee whose exclusive lock is held now returns STARTING (queued by automatic backpressure) instead of STARTED, and the rendezvous completion codes swap (COMPLETED|4 / DROPPED|4). Requires the queuing behavior, not just the candidate set.

Scope of the fix:

1. Drop the t !== task.inst.exclusiveThread exclusion in driveSyncLift; align the candidate set with merged canon_lift (all ready threads of the callee instance).
2. Adopt the surrounding merged semantics the new rows exercise: exclusive-lock interaction with the mini-scheduler, backpressure queuing of async-lowered entries while the lock is held (STARTING), and the trap-message alignment in the no-sibling case.
3. Retire the cm705-sync-sched xfail class; the stale-xfail detector enforces completeness.

Authority: design/mvp/canonical-abi/definitions.py at the advanced pin (tie-breaker), Concurrency.md §Reentrance/§Blocking as merged in CM#705. Scheduler core is single-owner territory (AGENTS.md): coder-hard at most, close orchestrator review.

[lannbot]

Scope re-derivation before implementation, two findings:

1. CM#716 overlap (open upstream, see #250). #716 restructures the callback event-loop turn (wait_from_callback, the YIELD/WAIT exclusive-lock dance) but does NOT touch this issue's core: the canon_lift sync drive loop's candidate set (the exclusive-thread exclusion removal) and canon_lower's backpressure/initial-status behavior are #705 semantics already at our pin, byte-identical in #716. Safe to implement now: driveSyncLift's exclusion removal, the during-sync-call-no-sibling-resume trap-message alignment ("cannot block a synchronous task before returning"). The callback-loop candidate rows (§3/§4/§6 of during-sync-scheduling-candidates) are #152-translate-blocked in the corpus anyway AND sit in #716's blast radius — implement them last, or after #716 settles.

2. The sync-streams.wast:208 row collides with the #43 adjudication. The row's new STARTING expectation is the pristine-definitions.py answer that #43 adjudicated as an upstream test defect when the expectation pointed the other way (STARTED, satisfied via the hold-gate + drain-to-quiescence entry policy mirroring wasmtime's deferred-entry model). CM#705 flipping the committed expectation is upstream declaring the pristine answer normative under the post-may_enter model — so adopting this row means revisiting #43's named adjudication, not just tweaking codes: the drain-to-quiescence entry policy itself is what answers STARTED. Check what wasmtime's deferred-entry policy looks like post-#705-adoption before choosing (the parity policy allows either conforming policy only if the corpus row is schedule-independent — and upstream has now made it the committed expectation, which was exactly the #43 exit condition's shape).

Sequencing consequence: this track is one PR with two reviewed decisions (exclusion removal — mechanical; entry-policy revision — adjudication-grade), not a mechanical sweep. The xfail class holds until then.