df.instance_nodes leaves race-loser nodes running or pending after race completion

[pinodeca]

Summary

After a df.race(...) workflow completes, df.instance_nodes can still show nodes from the losing branch as running or pending.

The underlying orchestration may have cancelled the losing branch correctly, but the operator-facing node view continues to look like work is still active.

Expected behavior

Nodes in the losing branch of a completed race should be marked with a terminal status such as cancelled or dropped, consistent with the parent workflow having completed.

Actual behavior

df.status(instance_id) reports the race workflow as completed, while df.instance_nodes still shows losing-branch nodes such as signal waits or downstream SQL nodes as running or pending.

Repro shape

1. Start a workflow using df.race(...) with one branch that wins and another branch that waits or has downstream nodes.
2. Wait for the parent workflow to complete.
3. Query df.instance_nodes for the instance.
4. Observe losing-branch nodes still reported as active or pending.

Impact

Diagnostics and dashboards that use df.instance_nodes to find stuck work can report ghost in-flight work for workflows that have already completed.

[pinodeca]

This one is similar to #240 (addressed by WIP #249):

• After a failure, steps are skipped and should be marked accordingly (240)
• After a race is won, steps in the other branch are canceled (if they were running) or skipped

Do we need to be able to distinguish these - potentially 3 - cases?