bash_detect rm-path hygiene + per-proposal tempfile tracking

[Cannon07]

Background

Phase 3 of #47 (PR #63) ports the core handler to in-process Lua with deliberate behavioural parity to the bash version. Two parity-adjacent improvements surfaced during code review on #63 but were judged out of scope for the parity port itself. Tracking them here.

1. Apply looks_like_path to rm tokens

bash_detect.detect_write_paths runs every captured candidate through looks_like_path (rejects leaked backslashes, double-quotes, etc.). detect_rm_paths does not — it treats every non-flag token in rm ... as a path. The bash core had the same gap, so this isn't a regression, but theoretical inputs like rm $(some-command) or rm '\n\n' (escape leak from a quoted string) would mark spurious paths as deleted in the changes registry.

Fix: thread looks_like_path (and shell_unescape) symmetrically through detect_rm_paths. Needs a few extra rows in pre_tool_bash_detect_spec.lua to lock the boundary, including a regression for the new false-positive cases.

2. Per-proposal tempfile tracking and cleanup

Phase 3 namespaces /tmp/claude-diff-{original,proposed}-* tempfiles by hrtime() + counter (collision-free) and adds a one-time startup sweep in setup() to match the old bash post-tool's wildcard rm -f. The startup sweep eliminates leaks across sessions, but within a single long-running Neovim session, tempfiles still accumulate forever — a 20-edit MultiEdit refactor leaves 40 files. macOS's /tmp policy doesn't evict files under a few days old.

Fix: track each proposal's tempfile pair in (or alongside) the active_diffs entry, delete them in diff.close_for_file. Falls out cleanly because we already have the file_path key. The diff.show_diff contract may need a small extension to receive the tempfile paths for tracking.

Why deferred from #63

• Item 1 is a behavioural change beyond bash parity — deserves its own justification and test surface, not buried in the parity port.
• Item 2 is an enhancement on top of the startup sweep landed in feat: in-process Lua core handler for claudecode (#47, phase 3) #63, which already plugs the cross-session leak that motivated the original review note.

Both are low-risk, additive changes that can land independently.