Background sessions should recover gracefully when working directory no longer exists

Problem

When a background session's working directory is deleted (e.g. a temporary scratch folder is cleaned up), the session enters a hard failed state with no recovery path:

{
  "state": "failed",
  "detail": "working directory no longer exists: /Users/sheldonels/Projects/scratch/2026-05-28_083323"
}

The only workaround today is to manually recreate the exact directory and retry. Users have no in-product way to know this, and for sessions created in temporary/dated folders this is a near-certain failure mode over time.

Expected behavior

When a session tries to resume and its original cwd no longer exists, it should:

1. Detect the missing directory at resume time rather than hard-failing silently
2. Prompt the user to choose a recovery directory (e.g. "The original folder /path/to/old no longer exists. Where should this session resume from?")
3. Resume from the user-chosen directory, updating cwd in the session state

Alternatively, fall back to a configurable default (e.g. $HOME or the project root) with a visible warning.

Why this matters

• Background sessions ("coffee sessions") are often created from dated scratch dirs that get cleaned up naturally
• The session's intent and timeline.jsonl are fully preserved — the conversation is intact, only the cwd is stale
• Hard-failing the entire session on a missing cwd throws away all that preserved context for a fixable condition

Steps to reproduce

1. Start a background session from a temporary directory (e.g. ~/scratch/2026-05-28_083323)
2. Delete that directory
3. Attempt to resume the session → it enters state: failed with no in-app recovery prompt

Environment

• Claude Code CLI v2.1.156
• macOS (darwin/zsh)