Reuse the compiled provider across runs

[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

Batch mode already reuses the loaded function module, but Javy/provider
functions still recompiled the embedded standard provider for every input
row. At scale, provider compilation dominated batch runtime.

What

• Store the compiled provider Module on Provider and compile it once,
  when the ValidatedModule is built.
• FunctionRunParams now carries a ValidatedModule (built once in main), so
  single and batch runs reuse the already-compiled function and provider
  modules — per-row work is just instantiation.
• Removes the now-redundant CompiledProvider type, the parallel
  *_with_compiled_provider entry points, and the per-row
  Module::from_binary fallback.
• Add batch coverage for a Javy v3 function to exercise the provider path.

Performance

Measured locally: 5,000 js_function_javy_plugin_v3 rows complete in
~1.2s, versus ~52s when the provider was recompiled per input row.

Testing

• cargo test
• cargo build --release

[dnagoda]

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