scrp-pane-tail.sh - one trimmed pane-read primitive, because the grep everyone reaches for saves nothing and the borders are the payload

Elazar's ask, CLI 2026-09-12, after using the raw pipeline three times tonight: 'what about script for this? tmux capture-pane -p -t <agent> | grep -v backslash-s-star-dollar | tail -22'. Carried off closed OPS-226 where it was a suggestion and would otherwise die with the row. MEASURED, bin-venus-cc's pane at 180 cols: full capture-pane -p is 46 lines, 2604 bytes, 1793 chars, roughly 400-500 tokens - higher than chars/4 because 366 of those chars are box-drawing rules that tokenise badly. The blank-line grep alone saves ALMOST NOTHING: 19 lines but still 2577 of 2604 bytes, because blank lines are one byte each. Border-stripped last 6 content lines is 344 chars, roughly 90 tokens, and still carries everything a caller needs: live spinner, model, effort, ctx percent and the 5h/7d meter. So the win is the BORDER STRIP, not the blank-line filter, and the default n is about 6 rather than 22. Also worth encoding: Elazar's earlier form 'tail -3 | head -2' is 146 chars and roughly 40 tokens but CANNOT answer is-it-working, because head -2 of tail -3 cuts the activity line that distinguishes busy from idle - a caller that wants cheap gets the one shape that cannot do the job. Suggested surface, not a mandate: scrp-pane-tail.sh <agent> [n=6], printing the last n non-blank content lines with horizontal rules stripped, exit 2 if the pane does not exist. WHY IT IS WORTH A ROW RATHER THAN EACH CALLER PIPING: a trimmed read should be cheap by default, not cheap when the caller remembers, and the pane read exists as a cross-check on scrp-monitor-agent-idle.sh which has now failed fleet-wide twice - so this is the instrument used precisely when the primary instrument is not trusted. Keep it independent of scan-context.py: the whole point is a second opinion that does not share a parser with the thing it is checking. HELD UNDER THE FLEET STOP.