[Bug]: Lineage list mixes working and finished threads instead of putting working ones first#29485

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web (thread details panel, Lineage section)

Steps to reproduce

1. In one thread, start several child threads: a mix of delegated tasks, subagents, and forks or launched threads.
2. Let some finish while others keep working.
3. Open the thread details panel and look at the Lineage section.

Expected behavior

Rows that are still working sit at the top of the list, above rows that are done, so I can see what is in flight without scanning the whole list.

Actual behavior

Working and finished rows are mixed together. The order does not follow status, so a running child can sit below several finished ones.

From the source on main (8657eecb28):

• orderWebThreadLineageRows in packages/client-runtime/src/state/threadRelationships.ts sorts by pin rank (parent, then merge target), then newest createdAt, then thread id. Status is not part of the sort.
• ThreadRelationshipsControl.tsx only splits rows by status for subagent edges (active vs previous). Forks and transfers all land in related and keep the status-blind order, so a working fork sits among finished ones.
• Inside active, every status not in the done list counts as active, and rows keep the same created-at order, so running rows do not lead.

A fix could add a status rank after the pin rank (running or pending first, then idle, then done or failed), using threadRelationshipRowStatus or the edge status, so it applies to every group.

Impact

Minor friction. Threads that delegate a lot of work have long lineage lists, and finding the children still running means reading every row.

Version or commit

v0.1.5, main at 8657eecb28

Environment

Linux, web client against a local t3 server

Workaround

Collapse "Previous agents" and scan the rest by eye.