Name the two spaces a photograph lives in, so a turn cannot go the wrong way

Every orientation bug this codebase has had has been the same bug: a turn of
the right size applied in the wrong direction. That failure is worth naming
precisely, because it does not look like one — a quarter turn applied
backwards lands 180 degrees from right, so the result is a plausible
transform of the picture rather than anything obviously broken, and on
landscape frames it is not wrong at all. It was the straighten shear, and it
was the segmentation overlay, and each time it was found by eye rather than
by a test.

The reason it keeps happening is that "rotate 90 degrees clockwise" cannot be
checked by reading it. The reader has to hold in their head which of the two
images is being rotated and which way the y axis runs, and there were four
hand-written copies of the permutation to hold it for: the shader prologue,
its CPU twin, the thumbnail path, and the segmentation.

So nothing added here says clockwise, anticlockwise, horizontal or vertical.
The functions say *which space they take and which space they return* —
`into_shown` and `into_stored`, `source_pixel` and `shown_pixel`,
`into_shown_rect` and `into_stored_rect` — and each takes the dimensions of
the space it reads from, so no caller has to work out which pair it is
holding. `StoredRect` and `ShownRect` are separate types because they are the
same four numbers meaning different things, which is exactly the case where a
mistake is silent: a shown rect measured against stored dimensions produces a
rectangle in the wrong place, not an error.

Underneath there is one permutation. `source_pixel` was already shared by the
prologue and the thumbnails; `source_point` is its normalised twin, written
beside it so the two cannot drift, and everything else is those two read
forwards or backwards. `Orientation::inverse` is the group inverse rather
than `4 - turns`: mirrors apply after the turn, so undoing means undoing them
first, and a mirror seen from the far side of an odd turn is about the other
axis. That is the diagonal-mirror case, tags 5 and 7, and getting it wrong
renders as — again — 180 degrees.

Three call sites lose their own copy: the thumbnail path, `dr-ui`'s
segmentation, and `dr-gpu`'s `local` example. "Upright" now means one thing
across the application rather than one thing per caller.

The gate that matters most is `the_render_and_the_orientation_map_agree`. The
shader prologue and `Orientation` answer the same question by different
routes, and until now nothing checked that they answered it the same way. It
now checks every EXIF tag against every user rotation and mirror on top of
it, because the composition is where the two could agree singly and disagree
together.

The rest earn their place by having caught something. Writing these found two
real errors in this commit's own new code before it ran anywhere: `shown_pixel`
was handed the dimensions of the wrong space and overflowed, and the rect map
turned the wrong way for the diagonal mirrors. A round trip that returns what
went in is the only check worth having here, since every wrong answer is
still a picture.

No behaviour changes. The permutations are the ones that were already being
applied; they are simply applied from one place now.

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

core/dr-decode/src/preview.rs

@@ -39,27 +39,14 @@ impl Preview {
     /// not: a quarter turn is a permutation, so it costs the same either way,
     /// and doing it on the smaller buffer moves a fraction of the bytes.
     ///
-    /// Allocates a second buffer rather than rotating in place. An in-place
-    /// quarter turn on a non-square image is a cycle-following permutation
-    /// that is both slower per pixel and far harder to get right, for a saving
-    /// that a thumbnail-sized buffer does not need.
+    /// The turn itself is [`dr_types::Orientation::into_shown`], which every
+    /// other consumer of an orientation in this codebase also goes through.
+    /// That is deliberate: a hand-written permutation per caller is how two of
+    /// them come to disagree, and a disagreement here shows as a thumbnail
+    /// facing the other way from the develop view.
     pub fn apply_orientation(&mut self, orientation: dr_types::Orientation) {
-        if orientation.is_normal() || self.width == 0 || self.height == 0 {
-            return;
-        }
-        let (dw, dh) = orientation.oriented_size(self.width, self.height);
-
-        let mut out = vec![0u8; (dw as usize) * (dh as usize) * 4];
-        for y in 0..dh {
-            for x in 0..dw {
-                let (sx, sy) = orientation.source_pixel(x, y, dw, dh);
-                let s = ((sy * self.width + sx) * 4) as usize;
-                let d = ((y * dw + x) * 4) as usize;
-                out[d..d + 4].copy_from_slice(&self.rgba[s..s + 4]);
-            }
-        }
-
-        self.rgba = out;
+        let (rgba, dw, dh) = orientation.into_shown(&self.rgba, self.width, self.height, 4);
+        self.rgba = rgba;
         self.width = dw;
         self.height = dh;
     }