passthrough_max_chars truncates output silently (no marker) — git log shows 50 of 252 commits, misleads scope

Describe the bug

[limits].passthrough_max_chars (default 2000) caps passthrough command output, but truncates silently — no ... N more lines marker, no hint that output was cut. A consumer (human or LLM agent) reads the truncated output as complete.

This caused a real correctness failure: git log <base>..HEAD on a 252-commit branch returned only ~50 lines. An automated agent read "50 commits", planned a history rewrite (squash/rebase) on that wrong scope, and had to redo work once the true count (git rev-list --count = 252) surfaced. wc -l on the piped output also reads 50, so even a line-count sanity check is fooled.

To reproduce

1. On a branch with >50 commits ahead of base
2. Run git log <base>..HEAD through the RTK hook (rewritten to rtk git log)
3. Output stops at ~2000 chars (~50 lines) with no indication it was truncated
4. git rev-list --count <base>..HEAD shows the true (larger) number

Expected

Truncation should be visible. Any one of:

• Append a marker when output is cut, e.g. … [rtk: truncated, N of M lines shown — full: rtk run git log …]
• Exempt history-listing commands (git log, git rev-list) from the char cap by default — these are exactly the cases where completeness matters
• Make the cap a line count rather than a char count for git log, and document it

Environment

• rtk 0.42.0 (Homebrew, macOS)
• Config at ~/Library/Application Support/rtk/config.toml — note: the README/docs reference ~/.config/rtk/. On macOS the active path is the Application Support one; might be worth documenting the platform difference.

Workaround

Added "git log" to transparent_prefixes so it bypasses the cap. Works, but the silent-truncation behavior is the real issue — a visible marker would have surfaced it immediately instead of after a wrong-scope history rewrite.