resources: guest-initiated dtors run without a Task — ambient built-ins attribute to the dropper

[lannbot]

From the 2026-08-20 conformance review. Sibling of #160 (which fixed the HOST-initiated side, PR #163); filed to record the guest-side gap and its intended reading.

The divergence

definitions.py canon_resource_drop (:2325-2331) runs the dtor through a full canon_lift, which constructs a fresh Task in rt.impl — with its own num_borrows, thread registration in inst.threads, and unregister_thread's resolved-state trap. deltic's guest-initiated drop (callDtorGated, runtime/src/cabi/handles.ts ~234-298) calls the raw dtor inside a hand-rolled enter/leave bracket with no Task behind it: any task-ambient built-in the dtor body reaches (waitable ops, context.get/set, borrow lowering) attributes to the dropper's task, not a dtor task in the impl instance.

The module comment documents the bracket reconstruction and the #85 suspension trap, but not the ambient-task substitution. Reachability is low (a dtor body using task-scoped built-ins), and routing guest drops through generated wasm was explicitly out of #85's scope.

Ask

Adjudicate one of:

1. Document the restriction — "a guest-initiated dtor body must not use task-ambient built-ins; they attribute to the dropper's task" — as the intended reading, in the callDtorGated comment plus docs/architecture.md §7's known-limitation note; or
2. Route guest-initiated drops through the same lift harness resources: host-initiated dtors run as full canonical lifts #163 built for host drops (createDtorEntry), synchronously driven — which fixes attribution and gives the dtor its reference-shaped Task, at the cost of touching the guest drop hot path.

Classification from the review: B (undocumented divergence), high confidence on the structural difference, low on practical reachability.