Let a photographer choose the film, and remember which one

The stock model rendered correctly and nothing could ask for it. This is
the picker, and the sidecar key that makes the choice outlive the session.

How the choice persists was the open question, and the answer was already
written down twice in sidecar.rs: `rating` is a top-level key "because a
rating is not an edit", and `masks` are one "because a layer is not a
scalar". A stock is that kind of thing -- a choice of material, not a
number a slider moves -- so it is a top-level key too.

It stores the **id**, not an index. Stocks are files that users add, so an
index would mean installing a profile silently changed which film every
existing photograph had been developed on. A name this build has no
profile for still round-trips untouched, because the alternative is that
syncing to an older phone quietly un-develops the picture.

Only the names travel. Turning one back into tables needs the profile
database, which dr-pipeline deliberately does not link, so `Version::apply`
clears the film and the session re-bakes -- after the parameters, because
the bake reads the film's own exposure sliders and the print balance is
solved against them. That is also why moving those sliders rebuilds the
lookup where no other control in the panel does: an enlarger's filtration
depends on how the negative was exposed.

The panel keeps its rule. It still names no operation and still generates
every control from a declared parameter kind; the stock gets a bespoke
control beside those, exactly as the mask stack does, and for the same
reason. The film's exposure and print exposure arrive as ordinary
generated sliders.

Two defaults worth stating. Picking a colour negative prints it, because
an unprinted one is an orange strip and offering that as the first thing
somebody sees after choosing Portra reads as a bug rather than as a
choice -- the toggle is there for anyone who wants the scan. And a paste
carries no film: a preset is a parameter map, and a stock is not a
parameter, so pasting one would paste a choice the clipboard never took.

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

core/dr-pipeline/src/ops/film_sim.rs

@@ -75,8 +75,15 @@ static DESCRIPTOR: OpDescriptor = OpDescriptor {
 /// - `exposure_matrix[l][c]` — layer `l`'s response to linear sRGB channel `c`.
 /// - `curves` — `CURVE_SAMPLES` density triples, uniform over
 ///   `[curve_log_min, curve_log_max]`.
-/// - `lut` — `lut_size³` linear sRGB triples in x-major order, uniform over
-///   `[0, density_max]` on each axis.
+/// - `lut` — `lut_size³` linear sRGB triples, uniform over `[0, density_max]`
+///   on each axis, with the **red axis varying fastest**: index
+///   `(b * size + g) * size + r`. That is the order a 3D texture upload
+///   expects, so the consumer hands the slice straight to the driver. Filling
+///   it the other way round transposes red and blue in the finished picture —
+///   which is a plausible photograph of the wrong colour, and which the unit
+///   tests on both sides of this seam happily pass, because each side is
+///   internally consistent. `dr-film` pins it; `dr-gpu`'s `film_sim` test
+///   catches it end to end.
 #[derive(Debug, Clone, PartialEq)]
 pub struct FilmTables {
     pub exposure_matrix: [[f32; 3]; 3],