fix(grep): tee log for +N more overflow now holds full untruncated lines

[albatrossflyon-coder]

Summary

Fixes #2988 (the tee-log-fidelity half of it — see scope note below).

rtk grep -r caps per-file results and truncates long lines via
clean_line, then points overflow at a tee log via a +N more ... [see remaining: tail -n +N ...] hint. The bug: clean_line's truncated output
is the only copy of each line kept in by_file's entries — the
original, untruncated text is discarded right after truncation. Both the
interactive display and the tee log build from that same already-lossy
copy, so the tee log — whose entire purpose is full-fidelity recovery —
was just as truncated as the display it's supposed to recover from. There
was no way to get a matched line's full text back once it crossed the
length threshold, even by following the tool's own pointed-to recovery
path.

Fix

by_file's entries now carry both the cleaned (display) text and the
original raw text: (line_num, is_match, cleaned, raw). The interactive
body output keeps using cleaned, unchanged. match_block — which
builds both the tee log content and the skipped_files overflow block —
now uses raw instead. Same compact display, but the recovery path
actually recovers.

Scope note

The issue also raised two related but distinct observations I left out of
this PR, since they're either a separate bug or a design call for a
maintainer:

• Whether the per-file cap / truncation should default to off (matching
  rtk read's behavior) is a design decision, not a pure bug — didn't want
  to bundle a behavior change into a fidelity fix.
• The "single-file mode ignores --max-len" observation looked like a
  possibly-separate bug in a different code path; didn't want to guess at
  a fix for something I hadn't isolated.

Happy to open a follow-up for either if a maintainer wants them tackled
separately.

Testing

• Reproduced the exact fixture from the issue (2 files × 30 matching
  lines, alternating short/padded-past-80-chars) against the local build:
  before the fix, the tee log's recovered lines were still ...-truncated
  exactly as reported; after the fix, tail -n +26 <tee log> shows the
  complete untruncated line text.
• cargo test: 2449 passed, 8 ignored, 0 failed (1 more pass than before —
  the new regression test)
• New unit test test_match_block_uses_raw_not_cleaned_content on
  match_block directly
• cargo clippy --all-targets -- -D warnings: clean
• cargo fmt --check: clean

[tapheret2]

Review: fix(grep): tee log for +N more overflow now holds full untruncated lines

Files: src/cmds/system/search.rs
Size: +31 / -7

Notes

• Static pass on the patch: no obvious blockers from the diff alone.

Thanks @albatrossflyon-coder — independent review on the patch.