Add batch mode for JSON Lines inputs

[dnagoda]

Stacked on #619. Review that PR first.

Why

To test a Function against many inputs today (a regression suite, recorded inputs, or fuzzing), you start function-runner once per input. Each process loads and compiles the Function and its provider again before it runs one input. Startup costs much more than the run itself.

1,000 inputs, release build, Apple M4 Pro, Wasmtime compilation cache warm:

Fixture	One process per input (main, v9.2.2)	--batch, one process
exit_code.wasm (Rust, WASI)	5.46 s	0.05 s
js_function_javy_plugin_v3.wasm (Javy plugin)	17.54 s	0.07 s

That is about 110x faster for the Rust fixture and about 250x faster for the Javy fixture.

What

--batch reads JSON Lines from --input or stdin and runs the Function once for each non-blank line. The Function module is compiled once, and #619's provider cache compiles the provider once. Each input gets a new store and instance, so state does not carry over between inputs.

For each input, the runner writes one JSON record on one line to stdout:

{"line":1,"success":true,"instructions":5069,"memory_usage":1088,"logs":"","output":{"exit":0}}
{"line":2,"success":false,"instructions":5069,"memory_usage":1088,"logs":"module exited with code: 1","output":{"exit":1}}
{"line":3,"success":false,"error":"Invalid input JSON: EOF while parsing a value at line 2 column 0"}

• line is the 1-based input line number. Blank lines are skipped, and you can still match each record to its input.
• All records go through serde. An error message with quotes or newlines stays one valid JSON line. If a result cannot be serialized, the runner writes an error record for that input, never partial output.
• If the Function output is not valid JSON, output is null and output_error gives the reason. This matches single-run mode, where that run still counts as successful.
• If the Function itself cannot run, for example because it imports both WASI and a provider that does not allow WASI, each input gets an error record with that reason.
• The default record has only the fields needed to check an outcome. Inputs can be large, and echoing each one back would roughly double the output size. --batch-full-output writes the same fields as --json, plus line.

Failure handling:

• By default, the batch stops after the first failed input. The record for that input is still written.
• --batch-continue-on-error runs all inputs.
• The exit code is 0 only if every input succeeds. A failed input means the Function failed (success: false) or the input could not run.
• A summary goes to stderr, for example Batch complete: 4 inputs processed, 2 successful, 2 failed.

CLI rules:

• --batch-continue-on-error and --batch-full-output require --batch.
• --batch cannot be used with the profiling flags.
• --schema-path and --query-path work with --batch. The new BluejaySchemaAnalyzer::with_analyzer parses and validates the schema and query once, then computes the scale factor for each input. With a 4,451-line Payment Customization Function API schema, 1,000 inputs to noop.wasm take 0.06 s. Parsing again for each input takes 0.23 s.

The README documents the input format, the record format, exit codes, and with_analyzer.

Single-run mode does not change.

Testing

• cargo test --locked: 35 unit tests and 36 integration tests pass; one existing test remains ignored.
• 13 new integration tests cover the record format, stdin and blank lines, fail-fast and continue-on-error exit codes, error records with quotes and newlines, invalid output, an invalid Function, full output, a Javy plugin Function, schema and query, an invalid schema, and flag rules.
• A new unit test covers with_analyzer with many inputs.
• cargo clippy --locked -- -D warnings and cargo fmt --all -- --check pass.