resources: host-initiated dtors run as full canonical lifts

[lannbot]

resources: host-initiated dtors run as full canonical lifts

Fixes #160. Design settled by the reference itself: definitions.py canon_resource_drop (line 2319) invokes the dtor through Store.lift with CanonicalOptions(async_ = False) — a full canonical lift. The held-bracket path this PR deletes was the divergence, not the fix candidate.

The bug (#160)

The host-initiated drop path (callDtorGated(allowAsync=true), the #85 shape) called the dtor bare and HELD enterFrom(null) — leaf and synthetic root — across the returned promise, with no Task/Thread behind the activation. Three structural defects:

• The wedge: the held bracket made the impl non-host-enterable, so Store.tick's enterability filter (scheduler: tick skips threads whose instance is not host-enterable #155) could never resume a suspension point belonging to the dtor's own activation — while the completion promise sat in pendingHostCalls advertising external work, parking every driver on it forever. Every deadlock detector reads a pending host call as "the host owes an event"; this was the one promise whose settlement needed the scheduler itself.
• The scheduler: resumeWith has the same not-host-enterable window as tick, and the tick fix cannot transfer #156 macro window: this was the runtime's only enterFrom(null) bracket spanning an await, locking every sibling instance through the shared synthetic root for the dtor's whole activation (pinned pre-fix by the new sibling test: mayEnterFrom(null) === false throughout).
• No ambient: built-ins reached inside the dtor had no task — between calls, currentTask() signalled PendingCapability before any park (the loud presentation, confirmed by running the new regression test against the old code); with a foreign ambient live, the Guest callback invoked with null context slot (wit-bindgen async_support.rs:578) — polymorph-tls webcrypto-composed target #24 misattribution class.

The fix

• createDtorEntry (exec/boundary.ts): the dtor's entry built with the existing createLiftedFunction — ft = [u32] → (), inert ResolvedOptions, coreType (i32) → (), per-mode enterWasm inside the harness. The activation gets a real Task/implicit Thread; the entry bracket releases at the first park (leave() before the drive); suspension points resume through tick; settled tails flow through scheduler: resumeWith has the same not-host-enterable window as tick, and the tick fix cannot transfer #156's serviceSettled; traps poison through the harness's own poison().
• hostDtorCall (exec/boundary.ts): the host-initiated drop entry — impl === null direct path unchanged; otherwise the lifted entry (executor pre-wires ResourceTypeInfo.dtorHost; direct-construction tokens get it lazily). Async failures park on store.hostFailure ??= (the existing channel). The completion promise is deliberately not registered in pendingHostCalls: that registration was the "external work" lie, and it had no consumer beyond the drivers it misled. The dtor's genuine external dependencies — its host imports — register themselves when they park.
• callDtorGated (cabi/handles.ts) keeps only the guest-initiated synchronous discipline (allowAsync removed); the resources: own-drop dtor bypasses may_enter gating and trap-poisoning; JS-initiated drops skip the promising entry #85 guest-side frame-rule limitation is untouched.
• One additive harness parameter, allowAsyncCompletion: a sync-typed lift whose caller needs no synchronous answer (only the dtor today — drop(): void is documented non-blocking) skips driveSyncLift, so a plain-mode thenable-returning (host JS) dtor parks instead of tripping the sync loop's bogus deadlock. Not a weakening: drive enforces the same deadlock trap asynchronously — the substitution jspi mode already makes unconditionally.
• Executor comment rewritten: the old "promising would leave the impl entered for a turn after every drop" hazard is gone by construction (bracket released before the hop; the hop-quiescence entry gate covers drop-then-call).

Pinned behavior changes (the #85 pins are revised — that behavior was the bug)

• "holds the gate until it settles" → does not hold the gate: impl.mayEnter === true while the dtor is in flight; no pendingHostCalls completion entry.
• New scheduler: the held async-dtor bracket can strand the dtor's own suspension points — a pendingHostCalls entry whose settlement needs the scheduler #160 regression pin: a dtor parked on a scheduler-resumable suspension point (under the harness, currentTask() resolves to the dtor's own task) completes once ready — on the old code this test dies at PendingCapability before the park, the loud presentation of the missing-task defect.
• New sibling pin: sibling instances stay mayEnterFrom(null) while a dtor is in flight (pre-fix: locked through the root).
• Rejected-dtor semantics preserved: store.hostFailure === boom, impl poisoned (mapCoreException passes non-RuntimeError rejections through unchanged).

Relation to #156/#161: this removes the only macro-time reachability window of the deferral class; the deferral itself remains correct and necessary for the synchronous windows.

Gates

just gates — full pass. Conformance 1416 commands: 1257 passed, 0 failed, no expectation changes; sched-seeds clean. Embedder surface unchanged (drop(): void still non-blocking, same failure channel), so the lockstep version is left alone per AGENTS.md.