fix(git): wire up status_max_files and status_max_untracked config limits

[molloyzak13]

git status has two user-configurable knobs in LimitsConfig — status_max_files and status_max_untracked — that have serde defaults and are documented in src/core/README.md, but no code ever reads them. The porcelain status formatter iterates every line without any cap, so setting status_max_files = 2 in config.toml is a silent no-op.

The root cause is that format_status_inner was refactored to a straightforward porcelain-lines iterator when the compact-status rewrite landed, and the cap logic was never ported across. The fields sat orphaned in config.rs ever since.

This wires them up. format_status_inner now accepts an optional LimitsConfig. When limits are provided (from run_status via config::limits()), tracked files and untracked files are counted separately and capped at their respective limits, with a "... +N more" hint appended when files are hidden. When no limits are passed, the existing unbounded path runs unchanged, so all existing tests pass without modification.

The public format_status_output and format_status_output_detached wrappers continue to work unbounded for backward compatibility. The only production caller that gets limits is run_status, which is the actual rtk git status execution path.

Verified with cargo test: 2194 passed, 0 related failures (1 pre-existing sandbox infra failure on test_tool_exists_finds_git), all 8 test_format_status_output_* tests pass, all 252 git-module tests pass. cargo check is clean.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}