Windows/Git Bash: session's Bash tool dies permanently (unalias: unsetenv, then "completed with no output") and does not recover on resume

## Summary

On Windows + Git Bash, a long-lived session's Bash tool can enter a state where **every** command fails and never recovers, even after restarting the CLI on that session. The failure is bound to the **session/process**, not the machine or the CLI version: sibling sessions open at the same time work fine, and a **brand-new** session on the exact same CLI build has a fully working Bash. Resuming the broken session (`--continue`/`--resume`) re-attaches to the dead shell and stays broken.

## Environment

- OS: Windows 11 Pro (10.0.22631), Git Bash (`/usr/bin/bash`, msys)
- Claude Code: reproduced across `2.1.270`, `2.1.272`, `2.1.273` (same session)
- Entrypoint: `claude-vscode`

## Symptoms (two phases in one session)

**Phase 1** — every Bash tool call returns only:

```
/usr/bin/bash: line 82: unalias: unsetenv: not found
```

...and the actual command does not run. This traces to the shell-language-gate preamble that runs before each command:

```
{ \builtin unalias -- 'unsetenv'; \builtin unset -f -- 'unsetenv'; } >/dev/null 2>&1 || true
```

At the same time, three shell snapshots written during this window (`~/.claude/shell-snapshots/`) contained a phantom line right after `unalias -a`:

```diff
# Unset all aliases to avoid conflicts with functions
unalias -a 2>/dev/null || true
+ alias unsetenv=':'
shopt -s expand_aliases
```

`diff` against a healthy snapshot shows only that extra `alias unsetenv=':'` line (plus an unrelated PATH version bump). On Git Bash `unsetenv` is neither a builtin nor a command, so `unalias unsetenv` errors; the error appears to break the `&&` chain of the composed `-c` script so the real command is never `eval`'d.

**Phase 2** — after restarting the CLI on the **same** session, every Bash call returns:

```
(Bash completed with no output)
```

...with exit 0 and no side effects (a `printf > file` writes nothing; a background job's output file contains only `[exited with code 0]`). This looks like the session's persistent shell child died and the CLI keeps writing commands to a dead pipe. It persisted across a CLI upgrade (2.1.272 → 2.1.273) within the same session.

## Key evidence that it's session-scoped

- Sibling sessions opened minutes apart on the same machine: Bash normal.
- A fresh session on the same 2.1.273 build: Bash works perfectly (this is the reliable recovery).
- Only re-opening the affected session keeps it broken.

## Possible trigger

The broken session's `cwd` was recorded with a **lowercase drive letter** (`c:\repos`) while healthy sessions used `C:\repos`. The lowercase form appears right alongside both phases and correlates with a resume by an external launcher. Possibly the snapshot/shell-reset logic on resume mis-handles the drive-letter case and captures/creates a bad shell.

## Repro (best-effort)

1. Windows + Git Bash, long session, `cwd` with a lowercase drive letter (`c:\...`).
2. Resume the session (`--resume`/`--continue`) one or more times.
3. Observe a snapshot capturing `alias unsetenv=':'`, then the session's Bash wedging (first the `unalias: unsetenv` error, later `completed with no output`).

## Workaround

Start a **new** session for the repo. Do not resume the session with the dead shell; upgrading the CLI or restarting the editor on the same session does not help.

Start by reproducing the resume flow on Windows with Git Bash and compare the broken and healthy files under ~/.claude/shell-snapshots/. Trace the shell-language-gate preamble and the --resume/--continue entry point, focusing on the unexpected alias and dead persistent shell. Done means resumed sessions execute Bash commands normally without the unalias error or silent no-output failures.

Written by the indexing model from the issue text.