[Bug] Top-level forked sessions are nested as subagents in Agents View

[goghcrow]

Summary

A saved top-level session fork can retain parentSessionPath while explicitly persisting rlmDepth: 0. Agents View currently classifies every saved session with parentSessionPath as a subagent, so top-level forks are nested behind expandable subagent rows instead of appearing as independent sessions.

Reproduction

1. Resume a saved session from a different working directory.
2. Choose to fork it into the current directory.
3. Exit the forked session.
4. Open Agents View with bare --resume.

The forked session header has both:

{
  "parentSession": "/path/to/source-session.jsonl",
  "rlmDepth": 0
}

Actual behavior

The saved fork is rendered as a subagent of its source session and may be hidden behind one or more collapsed subagents rows.

Expected behavior

• rlmDepth > 0: render as a subagent.
• rlmDepth === 0: render as a top-level session, regardless of parentSessionPath.
• Missing rlmDepth: preserve the existing parentSessionPath fallback for legacy saved sessions.

Source-level cause

On current main, summaryForUnifiedRecord() derives saved-session runtimeKind from parentSessionPath alone:

runtimeKind: saved.parentSessionPath ? "subagent" : "top-level",

This conflates fork provenance with RLM hierarchy even though readSessionInfo() already resolves and returns rlmDepth.

Proposed minimal fix

Use explicit depth when present and retain the current fallback only for legacy records:

runtimeKind: (saved.rlmDepth ?? (saved.parentSessionPath ? 1 : 0)) > 0 ? "subagent" : "top-level",

No session migration, daemon protocol change, new state, or compatibility layer is required.

Validation

I added a regression to the existing agents-view-state.test.ts suite covering both boundaries:

• a saved fork with parentSessionPath and rlmDepth: 0 remains a top-level row;
• a legacy parent-linked saved session without rlmDepth remains a subagent.

Local results:

• agents-view-state.test.ts: 66/66 passed
• npm run check: passed

A focused implementation is available in the automatically closed PR #1634. If this behavior and fix direction are accepted, please invite or vouch the contribution so I can reopen or resubmit it according to CONTRIBUTING.md.