Compute humanized bytes lazily

[dnagoda]

📚 Stack (bottom → top)

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

Stacked draft PRs on the fork; review bottom-up. Merge target is Shopify/function-runner once upstream write access is available.

---

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

[dnagoda]

Moved upstream to Shopify#593 now that write access is available. Closing this fork PR.