rate-limit-guard: statusline-shim resolve_tee() keeps executing an uninstalled plugin's tee (byte-identical clone of the #1787 context-guard defect)

[kyle-sexton]

Found during #1787 (fixed for context-guard in PR #1844): plugins/rate-limit-guard/scripts/statusline-shim.sh carries a byte-for-byte identical resolve_tee() to the pre-fix context-guard shim, so an uninstalled rate-limit-guard keeps teeing through superseded version dirs for the same ~14-day orphan window.

The two shims are deliberately NOT a registered byte-identical cluster in scripts/cross-plugin-source-registry.txt, so no drift gate will ever surface this — this issue is the only thing keeping it visible.

Remedy shape: port PR #1844's fix (the supported .orphaned_at marker check, plus the shell-syntax provenance test for sh -c peeling if that shim shares rule 2), with the same split-run regression proof. Consider whether the two shims should become a registered cluster or deliberately diverge — record whichever is chosen.

[kyle-sexton]

Scope correction: this is two distinct halves, and the second is mislocated in the body above

Surfaced while verifying the stranded post-merge review findings on #1252 (tracked under #1938),
against origin/main at cff36aa5c7. Both halves of the context-guard defect that #1844 fixed are
still live on the rate-limit-guard side, but only one of them is findable from this issue as written.

Half 1 — the shim's orphan check. plugins/rate-limit-guard/scripts/statusline-shim.sh:83-92:
resolve_tee() carries the temp_* filter and no orphan-marker check. This is the half this issue
body already describes, and it is the direct analogue of 3cbfaa89ae's
[[ -e "${cand%/scripts/statusline-tee.sh}/.orphaned_at" ]] && continue at
plugins/context-guard/scripts/statusline-shim.sh:117.

Half 2 — the unwrap rule, and it is NOT in the shim.
plugins/rate-limit-guard/skills/setup/SKILL.md:120-129 still states "Unwrap before you compose" as
a single-pass guard-prefix-only strip: no sh -c adapter rule, and no fixpoint. The context-guard
counterpart at plugins/context-guard/skills/setup/SKILL.md:133-161 is now two rules applied
repeatedly until a pass strips nothing.

The body above covers half 2 only as a hedged aside — "plus the shell-syntax provenance test for
sh -c peeling if that shim shares rule 2" — which both hedges a defect that is actually confirmed
present, and points at the wrong file. The rule lives in skills/setup/SKILL.md, not in
scripts/statusline-shim.sh. Anyone working this issue from its body will grep the shim, find no
rule 2, and reasonably conclude the half does not apply.

Why neither half self-surfaces. The two guard shims are deliberately not registered as a
byte-identical cluster, so no drift gate will ever flag the divergence. That file's last touch was an
unrelated docs fix in #1443.

Carry the narrowing across, not just the rule. #1844's first push peeled sh -c unconditionally
and review forced it narrow: rule 2 fires only when what remains is exactly
sh -c '<single-quoted string>' with nothing after the closing quote and the carried string
itself contains shell syntax — because the skill emits that adapter only for a renderer carrying
shell syntax, so an sh -c over a string without any was operator-written. That is what keeps an
operator's sh -c 'ulimit -n' intact. plugins/context-guard/skills/setup/evals/evals.json pins
both directions (id 8 non-compounding, id 9 genuine-sh-c-renderer-is-not-peeled). A port of half 2
that skips the provenance clause reintroduces the bug review already caught once.

No code change was made to rate-limit-guard by the stranded-findings run — one PR per plugin, and
#1844's author declined the same cross-plugin scope for the same reason.