[config] status_max_files and status_max_untracked are declared in LimitsConfig but never read

Problem

Two fields in LimitsConfig (src/core/config.rs:123-145) are declared with serde defaults and are user-configurable in config.toml, but no code reads them. The git status command never bounds its output by them.

Repro

1. Set values in ~/AppData/Roaming/rtk/config.toml (Windows) or ~/.config/rtk/config.toml (Unix):

   [limits]
   status_max_files = 2
   status_max_untracked = 1
   

2. In a repo with > 2 modified files and > 1 untracked file, run rtk git status.
3. Observe: the user's caps are ignored; status shows all files.

Evidence

src/cmds/git/git.rs contains the status formatting pipeline (format_status_output, format_status_inner, run_status) but zero references to config::limits() or to either field name. Verified by:

$ rg "limits\(\)|status_max" src/cmds/git/git.rs
(no matches)
$ rg "status_max_files|status_max_untracked" src/
src/core/README.md:90:status_max_files = 15
src/core/README.md:91:status_max_untracked = 10
src/core/config.rs:129:    pub status_max_files: usize,
src/core/config.rs:131:    pub status_max_untracked: usize,
src/core/config.rs:141:        status_max_files: 15,
src/core/config.rs:142:        status_max_untracked: 10,

The only references outside config.rs are in src/core/README.md documenting the config schema.

Suspected cause

The status command in git.rs:673 (format_status_output) was likely refactored to use a fixed-path porcelain parser that iterates the entire porcelain.lines() vec. The previous version probably bounded displayed rows; the refactor dropped the cap and the LimitsConfig fields were left orphaned.

Two options

Option A (preferred — wire them up): Re-add the cap in format_status_inner. The cap is non-trivial because the porcelain format groups by status (staged/modified/untracked) and the cap semantics from the docstring ("15 staged/modified, 10 untracked") need to apply per-bucket, not globally.

Option B (cleanup): Remove the two fields, their defaults, and the docs. If git status should not be configurable, it shouldn't expose the knob — users who set it will be confused by the silent no-op.

A third option: add a deprecation warning at config load time if the user has set these keys, and remove in a later major.

Environment

• rtk 0.42.4
• Confirmed against ~/rtk checkout, commit 878af7d on develop.

Related

• Issue #828: "docs: FEATURES.md missing 30+ truncation limits" — adjacent but distinct. #828 is about hidden hardcoded limits not being documented; this is about documented user-configurable limits that don't work.

Read src/core/config.rs:123-145 and the status pipeline in src/cmds/git/git.rs, especially format_status_output, format_status_inner, and run_status. Reproduce the configured limits with rtk git status, then inspect the existing config documentation and related issue context. Done means the project has a decided behavior for these orphaned settings and matching code, tests, and documentation or cleanup.