Handle stacked MultipartRelatedConsolidator with fpp > 1

[thopkins32]

Assisted-by: oh-my-pi:gpt-5.6-sol.

Closes #66

[genematx]

When the default join_method changed from concat to stack, MultipartRelatedConsolidator stopped deriving files_per_datum from chunk_shape and fell back to frame_per_point (default 1). Multi-frame image sequences (e.g. ophyd-async areaDetector TIFF with NumImages > 1) therefore registered a single file per datum, so the declared stacked shape (N, frames, H, W) could not be filled and reads raised a reshape error.

Fix: introduce a single _derive_frames_per_file() helper — the one source of truth for how many frames each file holds (chunk_shape[0] for concat and rank-aligned stacked chunks; 1 for the legacy file-per-frame multiplier/frame_per_point layout; the whole datum otherwise). files_per_datum is then datum_shape[0] // _derive_frames_per_file(), and the physical file layout is recorded in orig_chunks from the same helper. Because both derive from one place they can't disagree, which also fixes sub-array reads (read(0), read((0,1))): previously the legacy multiplier path set files_per_datum but not orig_chunks, so slicing a stacked multi-file datum raised a 422 reshape error. Concat, single- and multi-page rank-aligned stack, and the legacy file-per-frame multiplier cases are all correct for full and sliced reads.

TST: add a parametrized consolidator test (single/2/3-frame, non-divisor, inner-shape-mismatch, legacy multiplier) and a writer test that value-checks full and sub-array reads for single-frame, multi-page, and legacy-multiplier layouts; fix a vacuous assertion in test_tiff_and_jpeg_chunks that never checked the stack file count.

[genematx]

Awaiting Tiled v0.2.19 release before merging.