Add batch mode for JSONL function runs

[dnagoda]

📚 Stack (bottom → top)

1. Add batch mode for JSONL function runs #589 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.

---

Refs shop/issues-checkout#13420

Why

The function-runner is used by function-rerunner to replay production
function inputs for Checkout Blocks migration parity. Replaying hundreds of
thousands of inputs one process-per-input is dominated by process startup and
Wasm engine/module compilation, which is identical work repeated for every row.

What

Add a --batch mode that reads newline-delimited JSON (JSONL) inputs from a
file (--input) or stdin and runs the function once per line:

• Creates the Wasmtime Engine and loads the Module once, then reuses
  them across every input row — the expensive setup is amortized.
• Infers the codec (JSON vs. MessagePack) once from the module's imports.
• Streams one compact JSON result per line to stdout (JSONL out), so callers
  can parse results incrementally.
• --batch-continue-on-error keeps processing on per-line read/parse/execute
  failures, emitting a {"success":false,"error":...} record for the failing
  line; without it, batch mode fails fast on the first error.
• Prints a Batch complete: N processed, S successful, E errors summary to
  stderr so it never contaminates the JSONL on stdout.

Single-run behavior is unchanged — the existing path is factored into
run_single_mode and shares the same engine/module setup.

Testing

• cargo test
• cargo build --release

[dnagoda]

@davejcameron I created this draft PR to at least start the conversation about merging these changes into main. Is there any reason not to pursue that?

[jeffcharles]

It makes sense to me to add a mode where we batch a bunch of inputs and write a series of outputs.

The code changes seem a bit messier though. I think we could update the Provider struct to store Module instead of bytes to reduce the number of new abstractions (like CompiledProvider) and methods. Might be worth having the LLM take another pass at generating the code.

You can also open a separate PR to add preserve_order to keep the size of the diff more manageable for reviewing.

[dnagoda]

@jeffcharles Yep, code definitely needs to be cleaned up and split into distinct changes. It's a bit of a dumping ground at the moment.

[dnagoda]

Superseded by #595 (same branch dc.batch-mode, rebased onto latest main). This PR was auto-closed when the branch was force-updated; continuing in #595 as the base of the stacked batch-mode PRs (#595 → #590 → #591 → #592 → #593 → #594).