Auto Mode's destructive-action classifier misses remote/SSH commands with real production blast radius

## Summary

Auto Mode is documented to bias toward acting without stopping for confirmation on
reversible/low-blast-radius actions, while still flagging destructive or hard-to-reverse
ones. In practice, the classifier's notion of "destructive" appears tuned almost
entirely around local git/filesystem patterns (`rm -rf`, `git reset --hard`,
`git push --force`) and didn't flag a command that was arguably worse in real-world
impact.

## What happened

During a session working against a real remote server over an already-open
`ssh potato-remote` connection, the agent ran a cleanup pass after some ad hoc testing
and issued `docker rmi ghcr.io//:latest` on that remote host — intending to
remove a *test* image. That tag turned out to be the actual production image a live,
in-use feature depended on. The removal executed with no confirmation prompt and no
flagged risk, despite:

- It ran against a **remote production host**, not a local scratch environment.
- It **deleted an image tag a running production feature depended on**, which is a real
outage risk, not a reversible no-op.
- The correct/available image was still on GHCR, so it happened to be recoverable via a
re-pull in this case — but the classifier had no way to know that in advance, and
didn't need to know it to recognize the risk shape (removing a `:latest`-tagged image
a live service references).

## Why this seems like a real gap, not a one-off

The listed examples of "risky, needs confirmation" actions in Claude Code's own
documented safety guidance are almost all local-filesystem/git shaped: `rm -rf`,
`git reset --hard`, force-push, deleting branches. A destructive command issued over an
already-open remote session (SSH, a remote docker/kubectl context, etc.) targeting
shared/production state doesn't seem to pattern-match against those examples at all,
even though "destroys a running production dependency" is exactly the kind of
consequence that guidance is trying to prevent.

## Suggested direction

Broaden the destructive-action heuristic beyond literal local command patterns to also
consider *context*: a command run over/against a remote host already established as
"production" earlier in the same session (e.g. a documented `ssh ` alias, a
prior `docker compose ps` against a live deployment) should raise the same bar as a
local `rm -rf`/`git reset --hard`, regardless of which specific binary or subcommand is
being run (`docker rmi`, `kubectl delete`, `rm` over an already-open remote shell, etc.).

## Environment

- Claude Code CLI, Auto Mode permission mode
- Remote target: a self-hosted Docker Compose deployment reached via an SSH config alias

*Note: Issue written with Claude Code*

Start at the Auto Mode destructive-action classifier and its existing local git/filesystem risk patterns. Reproduce the remote scenario with an established SSH target and a docker rmi command, then trace how session context is represented. Done means comparable remote production-state commands reliably trigger confirmation while preserving the existing local safeguards.

Written by the indexing model from the issue text.