Add DESY P03 detector adapters (CBF + Lambda NeXus)

[Wiebke]

Adds two adapters for DESY beamline P03 detectors, plus the packaging/CI to build and test them:

• CBFAdapter: reads .cbf files via fabio, merging the CBF header into metadata. Subclasses ArrayAdapter, same pattern as the existing bl733 adapters.
• LambdaDetectorNexusAdapter + walk: the Lambda detector splits each frame across up to 11 module NeXus files; the walker groups a scan's module files into one node, and the adapter stitches them into a single array using each module's own translation/distance offset. Applies flatfield correction (skipped if already applied upstream), and supports an opt-in pad_to_detector_size to guarantee the full detector extent even when a module was switched off mid-scan.

Tests cover both adapters via round-trip registration + read through the tiled client, plus unit tests for stitching, flatfield, and frame-count logic. Fixtures are synthetic, sized down from the real module geometry.

Requires pip install ".[desy_p03]" (fabio, h5py, ndindex), or pixi run -e desy-p03 ....

To use the example config:

tiled serve config ./tiled_config_desy/config.yaml

The Lambda walker is not picked up by tiled serve config (no walkers slot there) -- registering Lambda data needs an explicit tiled register call:

tiled register <tiled_uri> --verbose \
    --adapter 'application/x-cbf=splash_tiled.external.desy_p03.adapters.cbf:CBFAdapter' \
    --adapter 'multipart/related;type=application/x-hdf5=splash_tiled.external.desy_p03.adapters.lambda_nxs:LambdaDetectorNexusAdapter' \
    --walker 'splash_tiled.external.desy_p03.adapters.lambda_nxs:walk' \
    ./data

Some considerations

• Module offsets come from each file's own translation/distance, not a fixed table -- a switched-off module writes no file at all, and the remaining files get renumbered, so filenames can't identify which module is missing. pad_to_detector_size is opt-in rather than automatic since a missing module's geometry can't be safely reconstructed from data alone; the caller has to say which known unit ("2M"/"9M", or an explicit shape) applies.
• Frame count is the minimum across all modules, not just the first file's -- real scans have been observed where one module logs one extra frame; trusting a single module's count risks an out-of-range read on a shorter one.
• pixel_mask's bit meanings are currently not known, bit 31 looks like an inter-chip gap marker, others are likely hot pixels etc. apply_mask defaults off.