Keep guards across restore owner handoff (#98700)
### What?
Prevent eviction or GC from clearing a task while the thread that
restored it hands the task back to its caller.
This is the first open layer in stack #98709. The construction-time GC
pin it builds on has already landed through #98688.
### Why?
A restore clears the category's `restoring` bit while still holding the
task lock. The old code then dropped that lock so it could notify
waiters without making them immediately contend on the same shard, and
finally re-acquired the task guard for its caller.
That creates a small but real gap: once the restoring bit is clear and
the lock is dropped, the task is considered evictable. Concurrent
eviction can remove the category before the restoring thread re-acquires
it. The restore then returns a task that no longer contains the data it
just loaded, leading to stale task references, missing task types, or
incorrect values.
The same interleaving exists for both single-task restoration and paired
task access.
### How?
Keep the existing task guard through `restored.notify(...)` and return
that same guard directly. Pair access likewise retains both guards
through notification.
Notification only wakes listeners; it does not acquire task locks or
wait for listeners to run, so retaining the guard cannot deadlock. Woken
waiters may briefly contend until the restoring call returns, but there
is no longer any unguarded interval in which eviction or GC can clear
the newly restored category.
This layer introduces no new state or pin accounting. The complementary
waiter-side handoff is isolated in #98728.
### Verification
- `cargo test -p turbo-tasks-backend --lib` (102 passed)
- `cargo test -p turbo-tasks-backend --test eviction --test
gc_resurrection --test gc_collection --test gc_interrupt --test
gc_stress` (19 passed)
- `cargo fmt -- --check`
- `cargo clippy -p turbo-tasks-backend --tests -- -D warnings`
Built on the construction pin merged in #98688. Followed by #98728.
<!-- NEXT_JS_LLM -->
<!-- fleet 6aa6acec-6286-4b03-86f4-13f4c7e2b2fa -->
Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>
