Bash post-tool clears neo-tree markers globally, wiping concurrent Bash command markers

[Cannon07]

Summary

When an agent issues multiple separate Bash commands that touch files (e.g. several rm/delete commands, or shell writes), accepting the first command clears the neo-tree markers for all of them, and the remaining commands stay unmarked.

Surfaces often with OpenCode (and any agent that emits multiple shell commands as a batch), but it is backend-agnostic and not Windows-specific.

Repro

1. Ask the agent to delete several files; the agent emits them as separate Bash commands.
2. Each command's PreToolUse marks its file(s) in neo-tree (deleted). All files appear marked.
3. Accept the first command.
4. Observed: every deleted/bash_* marker disappears, not just the accepted command's file. The remaining (still-pending) commands' markers are gone.
5. Expected: accepting one command clears only that command's file markers; the rest stay marked until accepted.

Root cause

lua/code-preview/post_tool.lua (Bash branch):

if tool_name == "Bash" then
  changes.clear_by_statuses({ "deleted", "bash_modified", "bash_created" })
  ...

The Bash post-tool clears by status, globally, rather than by the specific files in that command. It was written to avoid clobbering modified markers from concurrent Edit/Write, but it doesn't account for concurrent Bash commands clobbering each other.

Proposed fix

In the Bash branch, re-run shell_detect.detect(command, cwd) on the post payload (the command is in input.tool_input.command; detection is deterministic) and changes.clear() only those rm_paths / write_paths — mirroring how the ApplyPatch branch closes specific files via patch_paths. changes.clear(path) already exists.

Scoped clear, no global wipe; helps every backend.

Scope

Small, standalone fix. Add a regression spec (two Bash deletes pending → accept first → only its marker clears).