feat: deep handler semantics for effect rotation

[sini]

Problem: when scope.run installs scoped handlers (e.g. a value
provider), effects not matching the scope rotate outward to the
enclosing handler. If the outer handler's resume is an effectful
computation, those resume effects were processed by the outer
interpret loop — never re-entering the inner scope. This meant
scoped handlers were invisible to effects originating from outer
handler resumes.

Example: inner scope handles effect A. Computation sends effect B
(not in inner scope). B rotates to outer handler. Outer handler
for B returns resume = send "A" null. Previously, A was processed
by the outer interpret (unhandled → error). Now, A passes through
the inner scope's handlers first.

Solution: three changes in the trampoline.

1. effectRotate/effectRotateSlow tag rotation continuations with
   __rawResume = true on the queue.

2. interpret checks __rawResume: if true, uses resumeWithQueue
   (passes raw resume to rotation continuation) instead of
   resumeCompOrValue (which would eagerly splice resume effects
   into the interpret loop).

3. The rotation continuation uses resumeCompOrValue to route the
   raw resume through effectRotate, where inner handlers get
   first opportunity to handle the effects. Non-matching effects
   re-rotate outward as before.

This implements deep handler semantics as described in the algebraic
effects literature (Plotkin & Pretnar 2013, Koka, Eff, OCaml 5).
Continuations now capture the full handler stack — when a handler
resumes, the continuation runs with ALL handler layers still active.

Backwards compatible: all 1636 existing tests pass unchanged.
Plain value resumes (the common case) are unaffected.
3 new scope tests validate deep handler behavior.

[vic]

Awesome, thanks for detecting this and fixing.

Do you mind to include a test that demonstrates this feature?

[sini]

sniped

[sini]

actually it looks like you merged the pre-fix in

[vic]

Ok will merge from latest commit 23965f1 you pushed, is that the right commit ?

[sini]

yes

[vic]

done.

[sini]

FYI: It was only styling/rebasing to try and remove your 'den version' from my tree.

[vic]

oh, hahaha. I was keeping that den version on my vic branch just for me to know which PRs are still pending upstream, but if you prefer a linear history, I can remove that empty commit on vic branch.

[sini]

I assume you'll just drop/re-order it when you need to. :)

[vic]

yes, I do when our PRs get upstreamed.