fix(stream): decode lossily instead of dropping lines on invalid UTF-8

[albatrossflyon-coder]

Summary

Fixes #2994.

run_streaming's six call sites all read child stdout/stderr with:

BufReader::new(stdout).lines().map_while(Result::ok)

BufRead::lines() returns Err for a line that isn't valid UTF-8 (OEM/ANSI
bytes from a non-English-locale Windows tool, per the issue's cp850 repro).
map_while stops iteration at the first None — so one non-UTF-8 line
doesn't just get dropped, it silently discards every line emitted after
it too. A failing build whose error text happens to contain one non-UTF-8
byte can end up looking like a clean, silent success even though the exit
code is non-zero.

Fix

Added read_lines_lossy(), which reads raw bytes via BufRead::read_until
and decodes each line with String::from_utf8_lossy (invalid bytes become
U+FFFD) instead of erroring out of the iterator. Replaced all 6
.lines().map_while(Result::ok) call sites in run_streaming with it —
this is the single shared path every filter routes through, so the fix
covers all callers at once.

rtk pipe (cmds/system/pipe_cmd.rs) already fails loudly on invalid
UTF-8 stdin rather than silently, per the issue's own note — left as-is,
out of scope here.

Testing

• cargo test: 2448 passed, 8 ignored, 0 failed (no regressions)
• 4 new unit tests on read_lines_lossy directly, including one that
  reproduces the exact failure mode from the issue: an ASCII line, a line
  with an embedded invalid byte, then another ASCII line — asserts all 3
  lines survive instead of the third silently vanishing
• cargo clippy --all-targets -- -D warnings: clean
• cargo fmt --check: clean

[CLAassistant]

All committers have signed the CLA.

[albatrossflyon-coder]

Hi — just checking in on this one, it's been open about 9 days with no review yet. Happy to make any changes if there's feedback, or let me know if anything's blocking it. Thanks for maintaining rtk!

[albatrossflyon-coder]

Thanks for the review — pushed a fix addressing both issues in ae5d1ae:

• Ok(0) | Err(_) => None was treating a genuine I/O error the same as clean EOF, silently truncating output on a real read failure. Fixed by switching to your suggested BufReader::split(b'\n') approach, which surfaces the error via eprintln! instead of conflating it with EOF.
• The per-iteration Vec::new() allocation is gone with the same change — now reusing std's own buffered split instead of hand-rolling the read loop.

Added a test with a custom Read impl that yields good lines then a real I/O error, confirming the already-read lines are preserved and the error path doesn't panic or hang.

Verified clean against cargo fmt --all -- --check, cargo clippy --all-targets, and the full cargo test --all suite (2,449 tests, 0 failed) before pushing.

[KuSh]

Thanks LGTM!