Auto-backgrounded/interrupted Bash commands outlive their turn and can destructively race later commands

Long-running Bash tool calls that the harness auto-backgrounds (or that get interrupted/superseded mid-turn) keep executing invisibly across many subsequent turns. In my session, several superseded rm -rf <dir> && git clone … attempts completed minutes later and wiped a directory that newer commands had already successfully rebuilt — a destructive race the model couldn't anticipate because nothing surfaced the "dead" commands as still alive. It took several wipe/rebuild cycles to diagnose.

Requests:

1. Interrupting/superseding a command should actually terminate it (or clearly mark it as still-running).
2. Surface still-pending background commands prominently when a new command targets the same path — completion notifications exist, but nothing warns that a superseded destructive command is still pending.
3. Consider serializing auto-backgrounded commands that touch the same filesystem path.

Environment: macOS 26.5 (arm64), Claude Desktop 1.9659.2 with bundled Claude Code; GitHub integration connected.

Related, not duplicate: #61568 covers visibility/duration of intentional run_in_background tasks; this issue is about superseded/interrupted commands not terminating and destructively racing later commands. Fixing either helps the other.