feat: defer tasks without creating effects

[Rich-Harris]

In a handful of places, we're using effect(...) to defer work that only needs to happen once (like autofocusing an element). This is overkill — it means creating an effect object, attaching it to the tree, then later 'collecting' the effect during top-down traversal, executing the effect function (which involves checking its dirtiness, setting its status to clean, managing various bits of global state, a nested try-catch, etc) — even if we merge #11955 to mitigate the memory cost.

There is a much cheaper and simpler way that already exists in the codebase — queue_micro_task.

It feels like we could probably use it in more places, but when I tried it causes some tests to fail, likely because of subtle timing issues that don't apply to the things changed in this PR.

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 with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

🦋 Changeset detected

Latest commit: 91c2e30

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[dummdidumm]

The test fails could come from the behavior of flushSync: it does flush microtasks first, then the effects: https://github.com/sveltejs/svelte/blob/main/packages/svelte/src/internal/client/runtime.js#L758

Some of these one-off effects are used to ensure that the element is guaranteed to be inserted into the real dom, and that doesn't happen until after the other effects have flushed. Not sure if it's viable/correct to move the flushing of microtasks until after the effects, but we could try.

[Rich-Harris]

The test fails could come from the behavior of flushSync

Nah, was more subtle than that. Turned out it's just a finicky edge case around nested effects in deferred transitions, so I left those alone