Wrong information around starting_job during a retry run.

Describe the bug
starting_job is the job from which a user started a run.
This works perfectly when you start a run from trigger or a specific node but it's then wrong when you select a node from a previous run to do a retry run.

During a retry run, whatever job you have selected is picked as the starting_job when the run actually starts from the top(first node) of the workflow.

Version number Latest

If you're running on a tagged version, include the number: vX.Y.Z

If you're running locally with an unreleased version, the commit sha: 84b1bdc

I have reproduced this locally on main:

• Yes
• No

To Reproduce Steps to reproduce the behavior:

1. Go to a previous run
2. Select a job which isn't the first job of the workflow that allows a retry run
3. Do a retry run from there
4. You'll notice the history of your recent run has starting_job being the job you had selected but the workflow was actually executed from the top

Expected behavior
The starting_job should be whatever job that was executed first. In the case of a retry run, we start execution from the top, not the selected job the retry started from.

Screenshots If applicable, add screenshots to help explain your problem.

Additional context Add any other context about the problem here.

Start by reproducing the retry run from a previous run, selecting a non-first job, and trace where starting_job is assigned during retry execution. Done means the recent run history reports the first job actually executed—the workflow's top node—rather than the selected retry node.