Bug: fresh session created by bare 'claude' is never cleaned up after switching via /resume

Repro

1. Run plain claude (no args) from a fresh terminal — this immediately creates a new session transcript file on disk (before you've typed anything).
2. As the first message, type /resume and open the picker.
3. Either (a) cancel the picker (Esc) without selecting anything, or (b) actually select an existing session from the list and switch into it.

Result

In both cases the freshly-created session transcript from step 1 persists on disk, unused, and shows up as clutter in future /resume lists.

• In case (a) it contains only the cancelled /resume command.
• In case (b) it's silent/empty (no messages at all) — the process visibly switches into the selected session's content, but the original wrapper session file is never deleted or merged, it's just abandoned.

Verified with a live test: launched a fresh claude, ran /resume, and actually resumed an existing (unrelated) session. The old session's content loaded normally and browsing it did not touch its own transcript file's size beyond a small initial marker. But the brand-new wrapper session file created in step 1 remained on disk afterwards, byte-for-byte unchanged, and now permanently clutters the /resume list for that project.

Note

claude -r / claude --resume (the picker launched directly via CLI flag, before any session exists) does not have this problem — cancelling or selecting from that picker leaves no orphan, since no session has been created yet at that point. The bug is specific to invoking /resume as a slash command inside an already-created (fresh, otherwise-empty) session — regardless of whether the picker is then cancelled or a session is actually selected, the just-created fresh session is never cleaned up.

(Split out from #85906; scope corrected after further testing — originally reported as cancel-only, confirmed to also happen on successful selection.)