Fix how reference cycle is determined in registration tasks

[jluethi]

It currently looks for the acquisition metadata in the well and will raise an error if the same acquisition is present twice. This works as long as only 1 representation of the image is available (e.g. if illumination correction was not run or was run with overwrite) & same for apply_registration_to_image.

We need to figure out a way to make this still work in the case where we have both. Not trivial, because the well metadata does not know which of the entries with the same acquisition is the relevant reference cycle. (=> overall generalization for those tasks to handle multiple images with the same acquisition needed)

[jluethi]

Affects apply registration to image, because it tries to find the reference cycle based on OME-Zarr metadata

[jluethi]

Potential workaround: Add an init task to this parallel task, the init task finds the right reference_zarr_url based on filtered list + acquisition metadata (instead of acquisition metadata only atm)

[jluethi]

Good example of why all the image list metadata should be in the OME-Zarr

[jluethi]

I need to fix the get_acquisition_paths method of the NGFF Well & how it's used to avoid this. Also needed to support correctly updating the well metadata after running apply_registration_to_image with overwrite_input=False, so I'll tackle it as part of that. WIP PR in #710

[jluethi]

I have now lifted the requirement for wells only having a single image per acquisition and the get_acquisition_paths returns the list of paths to images with a given acquisition.

How we find the correct registration images in a given task afterwards?

• For the compound tasks, we can use the filtered list and only a single image should be of that acquisition (still assumes that all FOVs in the well have been fused into a single image)
• For the apply_registration_to_image, I use a heuristic to find the matching image. This works robustly if a well e.g. contains 0, 0_illum_corr, 0_processed etc. It would also not work if the FOVs have not been fused for most cases I'd assume.

I'd say we close this after https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/710 and can reopen if a) the heuristic causes issues b) we're starting to address multiple FOVs in separate images for registration