Interactive `claude --resume <invalid-id>` silently starts a new session instead of erroring (non-TTY mode already errors correctly)

Summary

Interactive claude --resume <invalid-id> silently starts a brand-new session instead of erroring. The same invalid input in non-TTY / -p mode fails fast with a usage error — the bug is specific to the interactive path.

Steps to reproduce

1. Pick a valid-looking but nonexistent session UUID, e.g. 00000000-0000-0000-0000-000000000000.
2. In an interactive terminal (TTY), run:

``
claude --resume 00000000-0000-0000-0000-000000000000
``

1. Observe: no error, no warning. A brand-new session starts (fresh sessionId, empty transcript) and sits idle at the UI as if the resume had succeeded.
2. Compare non-TTY behavior:

``
claude -p --resume 00000000-0000-0000-0000-000000000000 "hello"
``
This correctly fails fast with an error for the identical bad input.

Observed on v2.1.211 (Windows 11). Not re-verified on v2.1.214 — reproducing it deliberately leaks a phantom session (see impact below), so we stopped re-running it once mitigations were in place.

Expected behavior

Interactive --resume with a nonexistent session ID should fail fast (or at minimum warn and prompt), matching the non-TTY path's behavior.

Actual behavior

A new session is silently minted. In our setup it also registers a live roster entry (~/.claude/sessions/<pid>.json heartbeat) while never writing a transcript, which makes it invisible to transcript-based liveness checks.

Real-world impact

In a multi-session / multi-agent setup this is a silent resource leak: an unguarded scripted spawn that passed a stale session ID left a ~247MB claude.exe phantom process registered in a shared repo's session roster for hours. It was only caught by a purpose-built phantom detector we ended up writing. Any orchestration layer that resumes sessions by ID can hit this.

Related (but distinct) issues

• #72118 (open): claude resume without -- silently starts a new session — same downstream symptom (silent new session), but a different trigger (positional resume treated as a literal prompt), not an invalid ID passed correctly via --resume <id>.
• #42766 (closed): CLI hangs when --resume is given a nonexistent session name — opposite symptom, resume-by-name path. Hypothesis only: if that hang was fixed by falling back to a new session, today's behavior could be a regression-by-fix; we could not confirm a linked PR/commit from the issue.