docs(zarr-http-server): add an example serving a TIFF over HTTP

[d-v-b]

🤖 AI text below 🤖

tifffile.imread(path, return_as="zarr") returns a read-only
zarr.abc.store.Store backed by the TIFF's own tiles, so store_app can serve
a TIFF file directly — no conversion step, and no second copy of the data. This
adds an example demonstrating that.

What's here

• examples/serve_tiff.py — writes a pyramidal OME-TIFF, opens it as a
  Zarr store with tifffile, serves it with store_app, then reads it back
  both as raw HTTP responses (httpx) and through a Zarr client
  (zarr.open_group(server.url)), asserting the pixels round-trip.
• docs/guide.md — a Serving data that is not stored as Zarr section, and
  the example added to the guide's and README's example lists.
• tests/test_examples.py — runs the new example, alongside the existing
  two.
• pyproject.toml — tifffile>=2026.5.2 in the examples dependency
  group, which CI already syncs, so the test runs there rather than skipping.

Notes

• The version floor is real: 2026.5.2 is the first tifffile release whose Zarr
  store is a zarr format 3 Store, and the first with return_as. It is
  asserted in both the script's inline metadata and the test.
• Two behaviors the example documents inline, since both are mildly surprising:
  tifffile decodes each TIFF tile as it reads it, so the served metadata lists
  no codec beyond bytes and a compressed TIFF still goes over the wire
  uncompressed; and HTTP exposes no directory listing, so the example walks
  resolution levels from the multiscales metadata rather than
  Group.arrays(), which silently yields nothing over HTTP.
• Such a store reports read_only=True, so the existing read-only guarantees
  apply unchanged.

just lint, just test (214 passed), and just docs-check all pass.

🤖 Generated with Claude Code