VisuCoreAtsCenterDistance is ignored, so the affine assumes an isocentre origin on ATS systems (spec 12)

[gdevenyi]

From §6.2 of the format-conformance review against
FILE_FORMAT.md.

The gap

§7.2/§12: the patient-frame origin is the magnet isocentre on single-modality
systems, but on ParaVision 360 multi-modality systems with an ATS it is the
labelled subject position in the animal cradle instead.
VisuCoreAtsCenterDistance records that offset.

grep -r VisuCoreAtsCenterDistance brukerapi/ returns nothing, while the
parameter is present in 90 corpus visu_pars. Every affine — including the
corrected one in #156 — therefore assumes an isocentre origin. The single
dataset checkable here is isocentre-consistent, so this is a gap rather than a
demonstrated defect, but it is silent when it is wrong.

Proposal

1. Expose the parameter as Dataset.ats_center_distance (None when absent).
2. Offset the patient-frame origin by it when it is present and non-zero, and
   say so in the compatibility notes — the transform stays in the Visu/DICOM
   frame, only the origin moves.
3. Until a dataset with a non-zero value and an independent reference is
   available, warn once (RuntimeWarning) when the parameter is non-zero, so a
   user of an ATS system is told the affine assumes isocentre rather than
   discovering it downstream.
4. Add a origin= switch ("isocentre" / "cradle") if the two conventions
   both turn out to be wanted.

What would settle it

A PV360 ATS dataset with a non-zero VisuCoreAtsCenterDistance and a vendor
DICOM export of the same series: the sign and axis of the offset can then be
read off the difference between the two origins. If anyone has such a dataset to
share, that is the missing piece.

[headmeister]

Yes, I agree. We do not have access to an ATS system either, so we would need someone with a suitable ParaVision 360 ATS dataset—ideally including a matching vendor DICOM/NIFTI export—to establish and test the correct offset direction and sign.