perf(omezarr): open the z5 dataset once, not per tile

[sameeul]

Summary

Follow-up to the z5 3.0.1 upgrade (#360). Both OME-Zarr loaders opened the dataset on every tile read:

void loadTile(...) {
    auto ds = z5::openDataset(*zarr_ptr_, ds_name_);  // re-parses .zarray every call
    ...
    z5::multiarray::readSubarray<FileType>(*ds, view, offset.begin());
}

z5::openDataset re-stats and re-parses the dataset's .zarray metadata (shape, chunks, dtype, compressor) from disk each time. On a whole-slide image that's thousands of redundant parses of an immutable dataset.

This opens the dataset once in the constructor, caches the returned std::unique_ptr<z5::Dataset>, and reads every tile through the cached handle.

Why it's safe

• readSubarray takes a const Dataset&, so a single cached handle is safe to share across all tile reads, including the multithreaded tile-loader path (reads don't mutate the handle).
• The constructor already opens the store and throws on a bad dataset, so opening the handle there keeps the same failure semantics.
• Pure optimization: no change to what's read or returned.

Testing

Verified both readers (NyxusOmeZarrLoader and RawOmezarrLoader) still return exact pixel values and full-image checksums against the committed tests/data/omezarr datasets, including the multi-tile / partial-tile cases — those now read all tiles through the single cached handle, which exercises the reuse path directly. The existing test_omezarr.h GTest suite covers this; all assertions pass.

Scope

Two files, +23/-9, no behavior change. This is item 1 from the #360 review follow-ups (the highest-value, zero-risk one). The remaining follow-ups (8-bit/float16 dtype-string matching, float→uint32 truncation, added dtype test fixtures) change what inputs the reader accepts and will come as a separate PR with their own test data.

🤖 Generated with Claude Code