SP-RM attributes a later, unrelated absolute path as the `rm` target

[colorpanda82]

Version: @qoris/knox 2.3.6

Summary

SP-RM (destructive rm protection) reports the wrong target when a command
contains an rm and, later in the same text, an unrelated absolute path. The
rule appears to bind "the rm target" to a subsequent absolute path anywhere in
the command rather than to the token(s) in the rm argument position. The
result is a denial naming a file the command never deletes — including the
interpreter of a following command.

Steps to reproduce (verified with the bundled knox-test harness on 2.3.6)

rm -f /tmp/x.log; /bin/bash script.sh

Expected: allowed, or at most a verdict about /tmp/x.log (the actual rm
target).
Actual: BLOCK — destructive rm targeting /bin/bash [SP-RM].

Same misattribution with a variable target:

L="/tmp/x.log"; rm -f "$L"; /bin/bash script.sh        → BLOCK targeting /bin/bash
rm -f "$L" 2>/dev/null && /bin/bash scripts/foo.sh     → BLOCK targeting /bin/bash

Controls (correct behavior):

L="/tmp/x.log"; rm -f "$L"                             → ALLOW
rm -f "$L"; echo done                                  → ALLOW

Impact

Any script or one-liner that cleans up a temp file and then invokes an
interpreter by absolute path (/bin/bash, /usr/bin/perl, ...) is denied with
a message naming the interpreter as a destruction target. The message actively
misleads: a reviewer reading "destructive rm targeting /bin/bash" audits the
wrong thing. Each denial also counts toward the session circuit breaker.

Real-world hit (2026-07-30, twice): a test harness doing
rm -f "$LOG" ...; /bin/bash <hook-under-test> — a delete of its own log file
plus an interpreter invocation, reported as an attempt to delete /bin/bash.

Suggested fix

Bind the reported target to the argument list of the rm invocation itself
(tokens between rm and the next command separator ;, &&, ||, |,
newline), never to material after a separator. If the target is a variable or
otherwise unresolvable, say so ("rm with unresolvable target") instead of
borrowing the next absolute path in the text.

This looks like the same class as the BL-026 / SC-013 chmod-mode over-breadth
reported separately: the rule matches the right token in the wrong position.