docs: record the stored-format break, and say how the adaptive finders actually accumulate

The per-image image-scale B factor was dropped from the CBOR stream and from the written
HDF5, which is a change for anything reading those files, but the changelog listed it only
under the OpenAPI breaking changes.

The GPU adaptive finder test claimed both finders sum the rings in double. The CPU one
does; the GPU one stages a block's contribution in float before reducing across blocks in
double, deliberately, to keep the hot loop's shared footprint down. Say so, and say what
follows from it - detection compares integer pixel values, so a threshold that crosses an
integer flips every pixel of that value in the ring at once.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tests/AdaptiveSpotFinderGPUTest.cpp

@@ -71,8 +71,12 @@ std::vector<std::pair<int, int>> SortedCoords(const std::vector<DiffractionSpot>
 } // namespace
 
 // Spot-finding functionality: the fused GPU engine must reproduce the reference CPU adaptive finder's
-// spot list. The two share AdaptiveThreshold.h and the host connected-component extractor, and both
-// sum the rings in double, so the only difference left is the order the ring sums are accumulated in.
+// spot list. The two share AdaptiveThreshold.h and the host connected-component extractor. They do
+// NOT accumulate identically: the CPU sums each ring serially in double, while the GPU stages a
+// block's contribution in float before reducing across blocks in double (see the comment on the
+// kernel). So ring sigma can differ in the last bits, and since detection compares integer pixel
+// values against the threshold, a threshold that crosses an integer flips every pixel of that value
+// in the ring at once. That is the difference this test is bounding.
 TEST_CASE("AdaptiveSpotFinderGPU_SpotFindingParity", "[AdaptiveSpotFinderGPU]") {
     if (get_gpu_count() == 0) {
         WARN("No CUDA GPU present. Skipping AdaptiveSpotFinderGPU_SpotFindingParity");