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>

docs/CHANGELOG.md

@@ -27,6 +27,9 @@ This is an UNSTABLE release. It includes many experimental features, as well as
 * `image_scale_b` is removed from the `plot_type` enum, so a client requesting that plot now gets an error rather than a curve.
 * `azim_int_settings.high_q_recipA` and `spot_finding_settings.high_resolution_limit` are no longer `required`. Both mean "as far as the detector reaches" when unset and are omitted from the response instead of carrying a placeholder value, which raises in a client generated from an rc.160-or-earlier spec.
 
+**Breaking changes to the stored formats** - a consumer reading these fields must treat them as optional:
+* The per-image image-scale B factor is no longer computed, so `/entry/MX/imageScaleBFactor` is absent from newly written HDF5 files and the corresponding key is absent from the CBOR DataMessage and END blocks. Files written by rc.160 and earlier still contain it and still open; nothing in the pipeline reads it any more.
+
 ### 1.0.0-rc.160
 This is an UNSTABLE release. It includes many experimental features, as well as many AI generated fixes. We recommend using rc.152 for production use.
 

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");