Fixes#17033
Fixes#17050

This one's hell, and has revelead three different bugs:

Bug 1

commit in an each could happen long after the original context of the block effect is gone. That meansget_boundary() inrun might not get the correct active effect, maybe it's evennull at that moment. To fix it Ithink we need to capture then restore the context. Loads of tests failed with that approach, so I added another capture-restore within the commit function itself but there's still one test failing - still trying to find out why.

Bug 2

Each blocks get out of order because of race conditions and block effects not rescheduling when they should. Reproducible by clicking fast three times on the button in the reproduction of#17033. This is what happens:

1. run batch 1
2. run batch 2
3. run batch
4. batch 1 completes, wants to rebase batch 2/3.
   • Does update and run batch 2 first.
     That reruns each block because each blocks rely on the newer values (because of proxy each entry is a separate source).
     Since each'sarray method is not time traveling it's always the value of whatever batch ran last. Rerun also causes reinit of Circle.svelte because each logic destroys the old one
   • Does NOT run batch 3 because no overlap according to our "depends on distinct values" logic (since each block just reran and now has more dependencies on it so false negative).
5. batch 3 Circle.run completes, decrement 0, runs commit
   • Does NOT rebase batch 2 because of same reasons as 4.
6. batch 2 Circle.run completes, decrement 0, runs commit -> wrong end result

The reason for this is that block effects can change dependencies after a rerun and so a subsequent batch rebase could have a false positive or negative effect reschedule. To fix it we need to split up the rebase logic into two stages: First collect all effects of all batches that should rerun, then run them in a second loop.

Bug 3

each state is not properly time-travel-ready. Something goes wrong for keyed each blocks in#17033 still. The problem is that fine grained proxy means some array entries may appear undefined for subsequent runs when they shouldn't, but no further insights yet and no idea how to fix yet.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC:https://github.com/sveltejs/rfcs
• Prefix your PR title withfeat:,fix:,chore:, ordocs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.
• If this PR changes code withinpackages/svelte/src, add a changeset (npx changeset).

Tests and linting

• Run the tests withpnpm test and lint the project withpnpm lint