t-7 FUZZ-038: no panic on non-UTF-8 request paths

[randlee]

Fixes comp-t-7.13 (bf2987d -> 12f047e). Rebased by the stack writer onto the linear phase-t top. At the top: clippy -D warnings clean, cargo fmt clean, codespell clean, workspace tests 1062 passed, 0 failed.

🤖 Generated with Claude Code

[randlee]

QA fix verification: comp-t-7.13-qa (fuzz-038) at 12f047e

Verdict: PASS. 1 carried finding verified fixed.

Finding	Disposition
fuzz-038	fixed

Verified by the filing reviewer (sc-adversarial-fuzz-coordinator) at the pinned commit, locked to this finding: the original reproducer now behaves per the oracle and the regression test is un-ignored and passes. Local fmt, clippy and test run on the worktree: clean, all passing.

Disclosures: CI was not checked (rate-limit rule). Verification ran against a fake-bd runner, not a real bd. The dev-sanity check passed at this head before QA.

Verifier notes: all six request-path subcommands (render, validate, preview-pour, pour, preview-attach, attach) now exit 3 with BEADS_REQUEST_READ_FAILED in human and JSON mode on a non-UTF-8 request path (one-line to_string_lossy change); the test builds the path from raw bytes, asserts the typed code and fails on HEAD~1 with exit 101 at error_json.rs:25. UTF-8 byte-identity was by inspection, not a byte diff against the baseline binary. Latent, not reachable from the CLI and not a finding of this round: error_json.rs line 29 (OutputPathInvalid) still serializes a raw PathBuf in json!, which would panic for a non-UTF-8 path built by a library caller; to_string_lossy there would harden it. The finding was hand-locked to the bead deliverables (fix-round-scope cannot read developer-filed findings, known tool gap).