[BUG] Session forking (backgrounding/resume) has no parent-child linkage — compounds into unbounded duplicate-named entries for recurring jobs

Summary

Backgrounding a session, resuming from Agent View, or /resume in general all fork a new session ID that continues the conversation — but none of these surface any link back to the session they forked from. For a one-off fork this shows up as mild confusion (which of these two identically-named entries is current?). For a named background job that gets restarted/resumed repeatedly, it compounds into an unbounded, ever-growing list of same-named, unlinked entries with no way to tell which is live.

Evidence

Confirmed directly in local session transcripts: forking writes "Backgrounding after the current tool finishes…" as the terminal entry of the parent session, then the child session's first records (ai-title, agent-name) carry the identical display name forward with no reference to the parent session ID. One recurring named job in my own history has forked across 5+ session IDs over ~2.5 months, all showing identically in the session list.

Related issues (likely same root cause, different symptoms)

• #78264 — /resume forks duplicate custom titles onto new session IDs
• #70373 — backgrounding with in-flight subagents forks and orphans the original
• #83971 — backgrounding seeds the new job with only the last prompt, dropping prior context
• #76493 — resuming from Agent View forks (new id), freezes the original, empties the task list

Suggested fix

Either (a) collapse fork chains into a single thread in the session list with the ability to expand history, or (b) at minimum surface a "continued from" / "continues to" link between parent and child sessions so stale forks are identifiable and the relationship is discoverable.

Impact

Session list becomes unbounded clutter for any workflow that relies on repeatedly backgrounding/resuming the same logical task — which is exactly the pattern background jobs and named recurring tasks are meant to support.