Replace the per-body base curve with a scene-referred view transform

The base curve was a five-point spline on the unit square, flat past its
last point: every value above 1.0 left it as the same number, per
channel. Exposure and highlight recovery put values up there, and the
curve threw them away, then handed the result on as though it were
still scene-linear. The six per-body curves were also, by their own
file's account, hand-tuned shapes rather than measurements, and not
enough is known about where they came from to keep them (D19).

In their place, one view transform for every body (FR-DEV-3j): a
log-logistic sigmoid per channel, with the middle channel put back
between the other two so a hue survives the shoulder. Its two free
constants are solved from two conditions rather than set: scene grey
0.13, where the retired default curve put it, lands on display 0.18,
and the scene white four stops above grey lands on 1.0. So a highlight
a stop past sensor saturation still rolls into white, and the midtones
stay within 0.26 EV of the retired default between scene 0.03 and 1.0.
`dr_pipeline::view` holds the CPU reference and the WGSL, and the tests
there are FR-DEV-3j's acceptance criteria.

It is still fixed and still in the fused pass's tail, so a detail stage
still sees rendered values; the next commits make it an operation and
move it after the detail stage. It is skipped for a JPEG, as the base
curve was, and absent from the camera-space tap.

The base curve's database, its lookup and its twelve uniform slots go.
`RawImage` and `DemosaicedImage` lose the field, and the GPU test that
proved a curve reached the shader is replaced by one that renders the
view transform against the CPU reference and shows two highlights above
1.0 still render apart. The JPEG-and-sensor test now asserts the two
differ by exactly the view transform, where before an identity fixture
curve had made them match.

core/dr-pipeline/ops/README.md

@@ -294,40 +294,18 @@ in raw pixels is a different photograph on screen and in the exported file.
 ## What is not a node, and why
 
 Three things act on every pixel and are deliberately not in this directory:
-the as-shot white balance, the camera matrix, and the **base curve**
-(FR-DEV-3e). They are emitted by [`../src/operation.rs`](../src/operation.rs)
-into the composed shader's fixed preamble, around the block of nodes.
+the as-shot white balance, the camera matrix, and the **view transform**
+(FR-DEV-3j). They are emitted by [`../src/operation.rs`](../src/operation.rs)
+into the composed shader around the block of nodes.
 
-The test is not "does it transform a colour" — all three do. It is **whose
-decision is it**. A node is something a photographer chose: it has parameters,
-it moves off a neutral, it lands in the sidecar, it can be undone. These three
-are properties of the *file*, at the same standing as the masked-photosite crop
-(FR-RAW-3) and the stored orientation (FR-DEV-3h). Nobody chose the sensor's
-green sensitivity or the body's rendering; they are what reading the file
-correctly means.
-
-Making the base curve a node would have said the opposite in four places at
-once. It would have appeared in the develop panel as a control, so an
-unprofiled body would show a slider that does nothing. Its values would have
-gone into the sidecar, and sidecars are shared between devices and bodies
-(FR-NC-9) — one camera's rendering would follow an edit onto another camera's
-file. Its neutral would have had to be "the identity", so a profiled body would
-open reporting itself modified. And there is no seam through which a node could
-learn which camera took the frame: the profile arrives on the decoded image,
-travels through `DemosaicedImage` beside the matrix it belongs with, and is
-written into the uniform block by the same three lines in `dr-gpu` — which is
-exactly the path the matrix already took, because it is exactly the same kind
-of thing.
-
-What it *does* share with the tone curve node is the spline. The composer asks
-`ToneCurve` for its `curve_span`/`curve_eval` helpers rather than emitting a
-second copy, so a profile author placing a control point and a photographer
-dragging one mean the same thing by it.
-
-The order still reads correctly from this directory: the base curve runs after
-every node in the chain. That is the same reasoning `exposure` records under
-`placement:` — corrections to capture are only meaningful on linear values, so
-the rendering goes last.
+The first two are properties of the *file*, at the same standing as the
+masked-photosite crop (FR-RAW-3) and the stored orientation (FR-DEV-3h): nobody
+chose the sensor's green sensitivity, and reading the file correctly means
+undoing it. The view transform is different in kind — it is the one stage that
+maps scene-linear colour to a display range (D19, ARCH §6.14) — and it runs
+after every node, because corrections to capture are only meaningful on linear
+values. It replaced the per-body **base curve**, which was looked up by camera
+model and flat past 1.0, so it clipped every recovered highlight.
 
 ## Stages