[Bug] Inherited stale CLAUDE_CODE_SESSION_ID causes silent transcript loss without warning

Bug Description
Title: Inherited stale/cross-project CLAUDE_CODE_SESSION_ID causes silent transcript loss (no --resume entry, no warning)

What happens:
If a long-lived process is ever started from a shell inside a Claude Code session, it permanently inherits CLAUDE_CODE_SESSION_ID, CLAUDE_CODE_CHILD_SESSION=1, CLAUDE_CODE_EXECPATH, etc. Every claude later launched as a descendant of that process
treats itself as a child of the original session — which by then is dead and belongs to a different project — and writes no transcript to ~/.claude/projects/.... The session runs and responds normally; it just silently never persists and never
appears in claude --resume. No warning is shown, so it's indistinguishable from data loss.

In my case the long-lived process was the Plank dock (started once from inside a Claude session during a reboot recovery). It then poisoned every app launched from the dock — including the IDE → its integrated terminal → claude. All terminal
sessions in that IDE stopped persisting, while plain-terminal sessions were unaffected.

Environment:

• Claude Code 2.1.177, native install, claude doctor clean
• Linux (Ubuntu Budgie), JetBrains/PyCharm integrated terminal
• Inherited vars pointed at a dead session from a different project, created days earlier on v2.1.174

Repro:

1. In a Claude session, note $CLAUDE_CODE_SESSION_ID.
2. From that shell, launch a long-lived process (e.g. restart your dock/panel/IDE), then exit Claude.
3. Launch claude as a descendant of that process (e.g. a terminal it spawns). It inherits the old CLAUDE_CODE_SESSION_ID and CLAUDE_CODE_CHILD_SESSION=1.
4. Hold a conversation → no .jsonl appears in the project dir, and the session is absent from claude --resume.
5. unset CLAUDE_CODE_SESSION_ID CLAUDE_CODE_CHILD_SESSION CLAUDE_CODE_EXECPATH CLAUDE_CODE_SSE_PORT before claude → persistence returns.

Expected:
When claude starts with an inherited CLAUDE_CODE_SESSION_ID that is stale (its session is gone) or belongs to a different project/cwd, it should start a fresh persisted session — or at minimum print a visible warning that the conversation will not
be saved. Today it silently produces no transcript and no --resume entry, which looks identical to data loss.

Workaround (environment-side, for reference):
The stale vars lived in a long-running desktop process (the Plank dock) that had been started from inside a Claude session, so it poisoned every app it launched. Cleared without logging out by relaunching the dock from the systemd user manager's
clean environment:

```
pkill -x plank; sleep 1
systemd-run --user --unit=plank-dock1 --collect plank
systemd-run --user --unit=plank-dock2 --collect plank -n dock2

  
then fully quit and relaunch the IDE from the now-clean dock

After this, the IDE terminal showed only a fresh CLAUDE_CODE_SSE_PORT (integration still active) and claude persisted normally. This is a user-side mitigation; it does not address the silent-failure behavior in the CLI.

**Environment Info**
- Platform: linux
- Terminal: gnome-terminal
- Version: 2.1.177
- Feedback ID: 32085ba1-6bd1-4518-8378-3d8772b2c12f

**Errors**
```json
[]