rtk git status ignores status_max_files config limit on repos with many changed files

Environment

• rtk 0.44.1 (reproduced on 0.42.3 before upgrading too)
• macOS (Darwin 25.5.0)
• Config at ~/Library/Application Support/rtk/config.toml:

[limits]
grep_max_results = 200
grep_max_per_file = 25
status_max_files = 15
status_max_untracked = 10

Steps to reproduce

1. In a repo with > 15 modified files and several untracked files/dirs (real case: ~30 modified + 6 untracked = 36 entries).
2. Run rtk git status.

Expected

Output truncated/summarized per status_max_files = 15 and status_max_untracked = 10 (e.g. top N files + a count of the rest).

Actual

Full untruncated output, byte-for-byte identical to plain git status — all 36 entries printed, no truncation, no summary line. Verified this is not just visually identical but literally the same line count as running git status directly in the same repo.

Why this matters

This specific case — a repo with many changed files across several directories — is exactly the scenario where git status compaction has the most value (it's the highest-volume git subcommand in rtk gain/rtk discover reporting). If the configured limit silently doesn't apply once a threshold of directories or total entries is crossed (my working theory, untested), the real-world savings for rtk git status are likely overstated in aggregate reporting for exactly the sessions where it matters most (big multi-package monorepos with lots of concurrent WIP).

Secondary, smaller finding

rtk discover (no flags) silently scans 0 sessions even when run from inside an active project directory with hundreds of tracked Bash invocations in history — it only finds real data with --all. This isn't necessarily wrong behavior, but it fails silent ("No missed savings found. RTK usage looks good!") instead of indicating that project-scope matching found nothing to scan, which reads as a false "everything is fine" signal. Might be worth a distinct message when scanned session count is 0, e.g. "0 sessions matched project filter — try --all", rather than the same success message shown when sessions ARE scanned and genuinely show no gaps.

Happy to share the full git status output / repo file list if useful (contains only internal file paths, no secrets — can share privately if preferred).

Start by reproducing rtk git status in a repository with more than 15 modified files and compare its output and line count with plain git status. Trace how status_max_files and status_max_untracked are applied, then add coverage showing truncation and a summary; treat the separate rtk discover zero-session message as a distinct follow-up unless its scope is confirmed.