turbo-tasks: prioritize recomputed tasks with Recomputation priority (#93876)
### What?
Introduces a new `Recomputation` priority in `TaskPriority` that
schedules recomputed tasks (tasks re-run because their output or cell
wasn't available when read) ahead of all invalidation phases. Also
documents every `TaskExecutionReason` variant and removes the unused
`Local` variant.
### Why?
When a task is recomputed because a downstream consumer needed its
output/cell, that recomputation should run before lower-priority
invalidations so the consumer can make progress. Previously these
recomputations were scheduled with `Initial` priority, which placed them
alongside fresh work and behind ongoing invalidation phases, hurting
latency for the task actually being awaited.
Care is needed so the new priority doesn't spread virally: any
invalidation triggered during a `Recomputation` task must not itself be
tagged `Recomputation`, otherwise the priority would leak across the
graph and break ordering. The change therefore resets the priority to
`Initial` for invalidations triggered from a recomputation context.
### How?
- `turbo-tasks/src/manager.rs`: Add `TaskPriority::Recomputation`
variant, ordered before `Invalidation`. Update `Display` and `update`
impls.
- `turbo-tasks-backend/src/backend/mod.rs`: Schedule
output-not-available and cell-not-available recomputations with
`TaskPriority::Recomputation` instead of `Initial`.
- `turbo-tasks-backend/src/backend/operation/invalidate.rs`: When
`make_task_dirty_internal` runs under a parent task with `Recomputation`
priority, downgrade the propagated priority to `Initial` so the
recomputation marker does not spread. Also tighten the "already dirty"
branch so a stored `Initial` priority is always replaced by a more
specific parent priority.
- `turbo-tasks/src/task_execution_reason.rs`: Document each variant and
drop the unused `Local` variant (and its `as_str` arm).
Closes NEXT-
<!-- NEXT_JS_LLM_PR -->