`rtk read <file>` exits 1 with no output on a non-UTF-8 file, while `--head-lines`/`--tail-lines` on the same file are byte-exact

A plain read of a file that isn't valid UTF-8 exits 1 and prints nothing:

$ printf 'line one\nline two has a latin-1 byte: \xe9\nline three\n' > /tmp/nonutf8.log
$ rtk read /tmp/nonutf8.log
cat: /tmp/nonutf8.log: invalid utf-8 sequence of 1 bytes from index 38
$ echo $?
1

Same file, same binary, with a line window:

$ rtk read --head-lines 3 /tmp/nonutf8.log | cmp - /tmp/nonutf8.log && echo identical
identical

run() takes the byte path only when byte_line_window() returns Some, and that needs head_lines or tail_lines. A plain read has neither, falls through to String::from_utf8, and dies. The byte path is already byte-exact, it just isn't reachable without a window.

The hook decides which path a command lands on:

So cat on a log with one Latin-1 byte in it hands the agent an empty result, while head on the same file is fine. An empty result reads like an empty file.

CONTRIBUTING's Never Block rule covers this case: fall back to raw output instead of erroring out.

PR #1019 fixed it in April with a narrow gate (unfiltered, no window, no -n). A maintainer confirmed the bug on 2026-05-18 and asked for a rebase, the author rebased, and the branch then sat unreviewed until the stale bot closed it on 2026-09-14. I'll send a fresh PR against current develop.

• develop @ d402152, macOS 26.6.2 arm64
• also on 0.49.0 from brew, where the message reads stream did not contain valid UTF-8

Thanks!

Start in the command's run() path and inspect byte_line_window(), which currently selects the byte-exact path only for head or tail windows. Reproduce the plain read and windowed read commands with the non-UTF-8 sample, then verify that the unfiltered plain read follows the raw-output fallback described by CONTRIBUTING's Never Block rule and preserves the file bytes.