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-pipeline/src/framing.rs

@@ -921,6 +921,61 @@ mod tests {
     /// turn combined with a user flip — a phone portrait that the user then
     /// mirrors. Naive flag-ORing renders it mirrored about the wrong axis,
     /// which still looks like a photograph.
+    /// TRACES: FR-DEV-3h
+    /// The render's map and `dr_types::Orientation`'s must be the same map.
+    ///
+    /// There are two ways to ask "where does this output pixel come from":
+    /// the shader prologue (via [`Framing::source_at`], its CPU twin), and
+    /// [`Orientation::source_pixel`], which the grid's thumbnails and the
+    /// segmentation both go through. They are written independently and they
+    /// have to agree, or the photograph and everything drawn over it turn
+    /// different ways.
+    ///
+    /// A wrong direction is what this catches, and it is worth stating what
+    /// that looks like: a quarter turn applied backwards is 180° from right,
+    /// which reads as a deliberate transform rather than as a mistake. Checked
+    /// over every EXIF tag and every user rotation on top of it, because the
+    /// composition is where the two could agree singly and disagree together.
+    #[test]
+    fn the_render_and_the_orientation_map_agree() {
+        const SW: u32 = 8;
+        const SH: u32 = 5;
+
+        for tag in 1..=8u16 {
+            for user_turns in 0..4u8 {
+                for user_flip_h in [false, true] {
+                    let mut f = Framing::new();
+                    f.set_baseline(Orientation::from_exif(tag));
+                    f.rotate_quarters(i32::from(user_turns));
+                    f.set_param(FLIP_H, f32::from(u8::from(user_flip_h)));
+
+                    let effective = f.effective_orientation();
+                    let (dw, dh) = effective.oriented_size(SW, SH);
+                    assert_eq!(f.output_size(SW, SH), (dw, dh), "tag {tag}/{user_turns}");
+
+                    for y in 0..dh {
+                        for x in 0..dw {
+                            let want = effective.source_pixel(x, y, dw, dh);
+
+                            let out = ((x as f32 + 0.5) / dw as f32, (y as f32 + 0.5) / dh as f32);
+                            let (u, v) = f.source_at(out, SW, SH);
+                            let got = (
+                                (u * SW as f32).floor().clamp(0.0, (SW - 1) as f32) as u32,
+                                (v * SH as f32).floor().clamp(0.0, (SH - 1) as f32) as u32,
+                            );
+
+                            assert_eq!(
+                                want, got,
+                                "tag {tag}, user {user_turns} turn(s), flip_h {user_flip_h}: \
+                                 output ({x},{y}) — orientation says {want:?}, the render says {got:?}"
+                            );
+                        }
+                    }
+                }
+            }
+        }
+    }
+
     #[test]
     fn a_baseline_and_a_user_rotation_compose_into_one_permutation() {
         // Non-square and coprime, so no accidental symmetry hides an error.