rtk: single absolute rm -f operand is misparsed as rsync filter

[aider4ryder]

Supersedes closed #2842

Reproduction

Inside a Hermes native delegated task, the gate custodian used an absolute off-checkout receipt path:

set -uo pipefail
cd /home/obj/project/github/RyderFreeman4Logos/cli-sub-agent
log=/home/obj/tmp/3054-host-prepush-71bfd3bd-r1.log
rm -f "$log"
just pre-push >"$log" 2>&1

Actual behavior

Before the gate, the single-path rm -f was rewritten into an invalid rsync-filter operation:

Unknown filter rule: `/home/obj/tmp/3054-host-prepush-71bfd3bd-r1.log'
rsync error: syntax or usage error (code 1) at exclude.c(1213) [client=3.2.7]

The shell then continued because this custodian intentionally captured the gate's exit without set -e, contaminating an otherwise immutable exact-HEAD gate receipt with unrelated wrapper output.

Closed #2842 covered multi-path absolute rm -f. This reproduction shows the same semantic corruption for one absolute operand in the native-delegation/terminal rewrite path.

Expected behavior

rm -f "$absolute_file" must preserve /usr/bin/rm -f semantics for both existing and missing regular files. An absolute operand must never be interpreted as an rsync filter rule. If the optimizer cannot prove equivalence, it should decline the rewrite.

Impact

This breaks durable gate-log initialization and can make infrastructure output look like a product-gate failure. It also prevents reliable exit-fidelity wrappers from starting with a clean receipt file.

Acceptance criteria

• A regression test covers one absolute rm -f operand in the affected native/terminal rewrite path.
• Existing and missing regular-file cases both match /usr/bin/rm -f exit and deletion semantics.
• The operand is never parsed as an rsync filter.
• Multi-path coverage from fix(rtk): preserve multi-path absolute rm -f semantics #2842 remains green.