fix(merge): rebuild signal table at a uniform batch stride

[jayhesselberth]

Why

merge concatenated each input file's own Arrow signal batches as-is, offsetting only byte positions. Almost every POD5 file's own last batch is short (read count rarely divides evenly by batch size), so merging N files put a short batch from file k immediately before a full one from file k+1 at every file boundary but the last — breaking the constant stride dorado and the official pod5 library assume between batches (escapepod's own reader walks real cumulative row counts and is unaffected — same bug class as #195, writer-side).

Reproduced on real production data: merging 20 real multi-file flexizyme POD5 directories and basecalling the output with dorado 2.1 gave Failed to get read signal - 'Invalid: Too few samples in input samples array' on every one of them. escpod inspect summary independently confirms: Signal batches: NOT PORTABLE — signal batch 46 has 31 rows, expected 100.

What

merge now flattens every surviving (non-duplicate) read's compressed signal chunks across all inputs and rebuilds the signal table at one uniform stride via write_raw_signal_table — the same correctness-first approach filter/subset already used. That writer moved from operations::filter into utils::table_builders, next to the SignalRow/build_signal_batch primitives it's built from, since it's now shared by three callers instead of one (layering fix, not just the bug fix). Compressed bytes are still copied without decompression/recompression — only the Arrow batch grouping is rebuilt. MergeOptions gains signal_batch_size (default 1_000, matching FilterOptions).

Side effect, not the point of the change: a duplicate read's signal bytes are no longer carried into the output, since extraction now happens per-surviving-read instead of per-input-file (previously every input file's full signal table was copied regardless of later dedup).

Testing

• New regression test (merge_output_signal_batches_stay_uniform_even_with_short_trailing_inputs): merges two 150-read fixtures (each batches as [100, 50] under default WriterOptions) and asserts reader.nonuniform_signal_batch().is_none() on the output — this is exactly the shape that broke before the fix.
• cargo nextest run -p escapepod-pod5: 257/257 pass, including the existing merge_preserves_signal_bytewise (no recompression) and the full test_read_batch_geometry/test_merge_integration suites.
• cargo clippy -p escapepod-pod5 --all-targets -- -D warnings: clean.
• cargo build -p escapepod-cli: builds against the new MergeOptions field.
• Real-data validation: rebuilt the 16-file, 59,418-read lys flexizyme merge with this branch's release binary, then compared every read's signal array between the merged output and the original raw files using the official pod5 Python library (independent of this crate): zero mismatches, zero missing, across all 59,418 reads. escpod inspect summary no longer reports NOT PORTABLE on the new output (did on the old one, reproduced above).
• dorado 2.1 --emit-moves basecalling of both the raw directory and the fixed merged file no longer errors on either. (Basecalled read yield between the two differs — see follow-up note below; this is a separate, pre-existing issue, not a data-correctness regression from this change.)

Follow-up (not in this PR)

While validating, basecalling the full lys corpus via dorado 2.1 yielded 59,411/59,418 reads from the raw directory but only 34,186/59,418 from the merged file — despite the signal being byte-identical (proven above). The likely cause: collect_pod5_inputs (escapepod-cli/src/util.rs) sorts input files with plain Vec::sort(), which is lexicographic over filenames like ..._0.pod5, ..._1.pod5, ..._10.pod5, ... — scrambling the numeric/chronological file order MinKNOW wrote. If dorado's read-splitter relies on channel/time continuity across adjacent reads in the stream, concatenating files out of chronological order would explain a large, order-sensitive split-rate change with identical bytes. Worth a natural-sort fix and its own dorado-based verification as a separate change.