Verify format-neutral MCP entity discovery #55

Parent epic: #52

Correction (2026-08-19)

This subissue was originally framed as proving parity across OME-Zarr 0.4/Zarr v2 and OME-Zarr 0.5/Zarr v3. Review established that the MCP fixture never opens or interprets Zarr metadata, so that claim was incorrect. Actual storage-format interoperability belongs to copick core. The historical correction is also recorded on #58.

Objective

Verify that copick-mcp returns equivalent logical exploration results for equivalent Copick entity directory trees and does not introduce format-specific behavior.

Implemented work

• Exercise the exploration functions over deterministic equivalent Copick entity trees.
• Compare runs, project/object metadata, run details, voxel spacings, tomograms/features, picks, meshes, segmentations, and project statistics.
• Treat raw config root paths as an intentional fixture difference.
• Cover repeated calls, cache isolation/invalidation, missing entities, empty results, malformed config, and invalid paths.
• Remove fake v2/v3 metadata markers from the MCP fixture.

Acceptance criteria

• Equivalent Copick entity trees produce equivalent logical results.
• No MCP implementation branches on Zarr format, level name, chunks, shards, keys, or codecs.
• Error and empty responses remain serializable and readable.
• Tests do not claim to prove OME-Zarr/Zarr compatibility.

Non-goals

• Proving OME-Zarr 0.4/v0.5 or Zarr v2/v3 parsing and payload behavior; that is copick core coverage.
• Structural/source guards, payload-key guards, or before/after store snapshots.
• Direct volume/label reads, conversion, repair, or writer-layout validation.