Compute humanized bytes lazily

[dnagoda]

📚 Stack (bottom → top)

1. Add batch mode for JSONL function runs #595 Add batch mode for processing multiple inputs via JSONL
2. Preserve JSON input object order #590 Preserve JSON input object order
3. Refine batch failure handling #591 Refine batch failure handling
4. Reuse the compiled provider across runs #592 Reuse the compiled provider across runs
5. Compute humanized bytes lazily #593 Compute humanized bytes lazily
6. Add minimal batch output with --batch-full-output opt-in #594 Add minimal batch output with --batch-full-output opt-in

Stacked PRs — review bottom-up.

---

Why

BytesContainer eagerly built a humanized String (pretty-printed JSON or a
hex dump) on every construction, even though it's only needed when a
FunctionRunResult is actually displayed. Batch mode constructs a
BytesContainer per input row and never renders the humanized form, so this was
pure per-row overhead.

What

• Drop the stored humanized field; replace it with a HumanizedBytes Display
  wrapper that formats on demand.
• Invalid-JSON output now retains its raw bytes so the wrapper can reproduce the
  previous lossy-UTF8 rendering.
• Single-run output is byte-for-byte unchanged.

Testing

• cargo build
• cargo test