project: Re-resolve recent tasks against current editor context

[007qr]

Summary

Closes #55879.

When a task is run, its fully-resolved form (ResolvedTask, with $ZED_FILE/$ZED_STEM/$ZED_COLUMN/etc. already substituted) is cached in Inventory::last_scheduled_tasks. The next time the task picker is opened, used_and_current_resolved_tasks returns those cached entries as-is for the "recent" section. The "current" section is re-resolved against the active editor, but the label-based dedup keeps the stale recent entry.

The result is that $ZED_FILE keeps pointing at the file that was active the first time the task ran, even after switching editors and re-running from the picker.

This fix re-resolves each entry in the recent-tasks list against the current TaskContexts using the same context-pick chain the "current" branch already uses (item context → active worktree → other worktree → default). If re-resolution fails for any reason, we fall back to the cached ResolvedTask so behavior never regresses.

The change is localized to previously_spawned_tasks inside used_and_current_resolved_tasks. List order, dedup, and LRU scoring are unchanged — only the variable substitutions inside each ResolvedTask are refreshed.

Test plan

• Open a project with two source files (e.g. 1.cpp, 2.cpp) and a task that uses $ZED_FILE (e.g. g++ $ZED_FILE -o $ZED_STEM && ./$ZED_STEM).
• Open 1.cpp, run the task from the picker, confirm it compiles 1.cpp.
• Click 2.cpp, open the task picker, pick the same task from the "recent" section, confirm it now compiles 2.cpp (previously: still 1.cpp).
• Confirm the recent-task ordering and divider in the picker are unchanged.

Release Notes:

• Fixed task variables like $ZED_FILE not updating when re-running a recently used task after switching the active editor ($ZED_FILE doesn't update #55879).

[ConradIrwin]

I think the change is good.

Let's factor out the task context resolution to make it clearer; and fix the cargo fmt issues.

One thing I'm not sure about is fi we can re-use the active item context if the active item has changed (though maybe that is important).

Either way it'd be good to add a test for the new behavior so it doesn't regress.

[007qr]

Hey @ConradIrwin,
I have factored out the resolution into TaskContexts::reresolve_task and added tests. Fixed fmt.
On reusing the active item context: re-resolving against it is intentional, it's the only context with $ZED_FILE/selection, so it's what makes the recent task follow the current editor. Worktree tasks stay scoped to their own worktree, and it falls back to the original task if nothing resolves.

[ConradIrwin]

Thanks!

[007qr]

Hi @ConradIrwin,

The run_tests failure was tasks_ui::modal::tests::test_language_task_filtering, re-resolution was rewriting history task labels against the current file's context. Fixed by keeping the original label when re-resolution changes it. Verified locally.

Mind re-running the workflow? Thanks!

[cole-miller]

@zed-industries/approved