o8v-fs: no file-size guard on read_to_end / safe_read — latent OOM

[xsoheilalizadeh]

Summary

o8v-fs reads file contents into Vec<u8> with no size cap. The most visible site is safe_append_with_separator (which holds an exclusive flock during the read), but safe_read and other read_to_end call sites in o8v-fs are also unbounded.

Why this matters

Running 8v write --append on a large log file or binary will allocate and hold the entire file in memory under the lock. A 1 GB file → 1 GB heap → potential OOM. Same shape applies to safe_read for any large file.

What "fixed" looks like

• A crate-level constant MAX_FILE_BYTES (or similar), e.g. 64 MB, configurable
• Functions that currently do read_to_end either (a) return an error when the file exceeds the limit, or (b) stream where it's feasible (append's separator detection only needs the last few bytes once we know the file is well-formed; mixed-ending validation can be a streaming scan)

Out of scope

• Changing the public API of safe_read to return a streaming iterator. That's a bigger redesign.
• Per-command flags. The limit should be a static crate-level guarantee.

References

• o8v-fs/src/write_guard.rs::guarded_append_with_separator — current full-file read under flock
• o8v-fs/src/lib.rs::safe_read — same pattern, no flock but same unbounded behavior
• Surfaced during PR fix: preserve CRLF line endings in 8v write append and find-replace #4 review.