Record what per-display colour actually cost

The status table said FR-DSP-8 was absent and §5.2 assumed Slint
reports window moves. It does not — there is no `on_moved` on any
backend — so the position is sampled instead.

§5.4 records the two trades that are worth someone finding later: a
display profile is matched to the nearest of four spaces rather than
applied through a CMM, and on Wayland the canvas follows the first
output rather than the window, because a Wayland client is never told
where its window is and the protocol's own answer needs a `wl_surface`
that Slint does not expose.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ui/dr-ui/src/develop.rs

@@ -2756,7 +2756,11 @@ impl DevelopSession {
     /// explicit about. It is in the output colour space, which is what
     /// FR-DSP-7 asks for — the levels counted are the levels the display will
     /// show, so a clipped bin means a highlight that is actually gone rather
-    /// than one the transform might still recover. And when the view is zoomed
+    /// than one the transform might still recover. Since FR-DSP-8 that is the
+    /// space of *this display* rather than sRGB, which makes the reading more
+    /// truthful and not less: a highlight that survives on a wide-gamut panel
+    /// and clips on the laptop's screen genuinely is two different facts, and
+    /// the histogram now reports whichever one the photographer is looking at. And when the view is zoomed
     /// or cropped it describes the visible region, not the whole file: a
     /// photographer inspecting a highlight at 4× is asking about *that*
     /// highlight, and a histogram of the parts of the frame off screen would