[albatrossflyon-coder]

Fixes #3106.

The bug

engine_capture() and passthrough() in search.rs called exec_capture_stdin, which wraps Command::output() and buffers the entire child process's stdout/stderr in memory with no limit — on a large search corpus this could consume 50+ GB before the 200-result cap in search.rs ever gets a chance to apply.

The fix

rtk already has a memory-safe capture path for exactly this: run_streaming with FilterMode::CaptureOnly reads line-by-line through the existing RAW_CAP (10 MiB), already covered by test_run_streaming_raw_cap_at_10mb in stream.rs. It just wasn't being used by grep/rg.

Added exec_capture_stdin_bounded as a thin CaptureResult-shaped wrapper around run_streaming, so both call sites in search.rs needed a one-line swap — no changes to search.rs's grouping/capping logic at all. Removed the now-unused exec_capture_stdin (the unbounded function this replaces).

Testing

• Full suite: 2457 passed, 8 ignored (unchanged — the bounded-capture behavior itself is already covered by test_run_streaming_raw_cap_at_10mb, so this PR doesn't need new unit tests to prove that mechanism works; it only needed to prove search.rs is actually using it).
• Manual verification: rtk grep against a real 36MB file where every line matches. Completes cleanly (exit 0) and stderr shows [rtk] warning: output exceeds 10 MiB — filter input truncated — proof the cap is genuinely active now (this warning could not have fired through the old unbounded path).
• cargo fmt --check and cargo clippy --bin rtk -- -D warnings: both clean.

[KuSh]

Closing in favour of #3849, which bounds the same unbounded search capture and goes further: it caps per line as well as per stream, reaps the child on a broken pipe, and adds regression tests for both cases. Please take any further discussion of the capture path to that PR.