Stop describing a base curve the pipeline no longer has

D19 retired the per-body base curve, moved the matrix ahead of the
edits and the film into the view transform's place, but a dozen doc
comments still listed the curve among what a pixel passes through, or
said the film skipped it. The detail stage's module doc still drew the
matrix after the edits and the last detail pass encoding, which the
view pass took over. The film crate's README gave the base curves as
its reason for being data, and the ops README's list of hand-written
nodes had neither the view transform nor three of the five kernels.

FR-MRG-2 gave the base curve as why the merge cuts below the profile;
the view transform is why now. The decision table still said colour
defaults were a per-body curve, and FR-DEV-3j said only the default
view transform skips a JPEG, where the node skips one whatever its
sliders say. frame-budget.md records the view pass as unmeasured.

core/dr-pipeline/src/detail.rs

@@ -24,9 +24,10 @@
 //!        v
 //!   +------------------------------------------+
 //!   | the fused point-operation pass           |  one dispatch
-//!   |   white balance, exposure, tone, colour  |
-//!   |   the mask layers                        |
+//!   |   white balance (camera RGB)             |
 //!   |   camera RGB -> linear sRGB              |
+//!   |   exposure, tone, colour                 |
+//!   |   the mask layers                        |
 //!   +------------------------------------------+
 //!        |  rgba16float, linear, **unclipped**, at render resolution
 //!        v
@@ -34,7 +35,13 @@
 //!   | the detail stage - this module           |  one dispatch per pass
 //!   |   sharpen, NR, clarity, texture, spots   |
 //!   +------------------------------------------+
-//!        |  the last pass applies the output transform
+//!        |  rgba16float, still scene-linear and unclipped
+//!        v
+//!   +------------------------------------------+
+//!   | the view pass                            |  one dispatch
+//!   |   view transform, or the film stock      |
+//!   |   output transform, mask reveal          |
+//!   +------------------------------------------+
 //!        v
 //!   rgba8unorm display or export texture
 //! ```
@@ -52,14 +59,13 @@
 //! texture, clarity, spot removal and sharpen/NR sit below the tone curve and
 //! the colour mixer.
 //!
-//! **In linear light, after the camera matrix.** The fused pass works in
-//! *camera* space, because white balance and exposure are physically
-//! meaningful there and nowhere else. A detail pass is the opposite case: it
-//! wants a luminance, and camera RGB has no luminance — the three channels are
+//! **In linear light, after the camera matrix.** A detail pass wants a
+//! luminance, and camera RGB has no luminance — the three channels are
 //! whatever the CFA's dyes passed, and weighting them 0.2126/0.7152/0.0722
-//! would be numerology. So the split is taken *after* the `cam_to_srgb`
-//! multiply, where the working space is linear sRGB and a luminance is a
-//! luminance.
+//! would be numerology. Since D19 only white balance runs in camera RGB; the
+//! `cam_to_srgb` multiply follows it, so every point operation, and every
+//! detail pass after them, works in linear sRGB primaries, where a luminance
+//! is a luminance.
 //!
 //! **Before the output transform, and before the clip.** FR-DEV-2 allows
 //! exactly one quantisation, at the display or export stage. A detail pass
@@ -70,9 +76,11 @@
 //! therefore `rgba16float` and holds linear values that have **not** been
 //! clamped to `0..=1`: a recovered highlight is still above one at this point,
 //! and clipping it before the sharpener sees it would put a hard edge exactly
-//! where the sharpener is most visible. The last detail pass performs the
-//! primaries conversion, the clip and the encode, so the single quantisation
-//! stays single.
+//! where the sharpener is most visible. Every detail pass writes such an
+//! intermediate, the last one included, and the view pass after them — the
+//! view transform, then the output transform's primaries, clip and encode —
+//! is the one place the scene is fitted to a display (D19, ARCH §6.14), so
+//! the single quantisation stays single.
 //!
 //! **After framing, at render resolution.** The alternative — running detail
 //! on the demosaiced source before the framing prologue — is superficially