Give the tone curve a curve for each colour channel

The declaration in ops/tone_curve.yaml has claimed per-channel curves since
it was written — it is the justification for the operation carrying both
`tone` and `colour`. Only the master curve existed. This is the other three.

The master runs first and the channels grade its result. Both orders are
real images and they differ visibly, so the choice is made and written down
rather than left to the loop: a point placed on the blue curve should act on
the tone the photographer can see, which is what the master has already
produced. The other order anchors the grade to tones the master is about to
move, so adjusting contrast slides a warm shadow up into the midtones.

Every id that existed before today is spelled exactly as it was. The master
curve keeps `p2_y` and the new curves take `r_`, `g_` and `b_` prefixes, so
a sidecar written when there was one curve loads, means what it meant, and
renders the same shader — asserted on the generated source, not on the
parameter values. Nothing needed a version check because nothing was
renamed.

Each curve reaches the shader only when it has been moved off the diagonal,
so an S-curve and no colour work generates what it generated when this
operation held ten parameters instead of forty, down to the uniform names.
The monotonicity guarantee is enforced per curve: a coincident pair on blue
divides by zero exactly as thoroughly as one on the master.

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

core/dr-pipeline/ops/README.md

@@ -209,9 +209,10 @@ They still belong in this directory, because the pipeline's **order** is the
 one thing a reader comes here to learn, and an order written half in YAML and
 half in Rust would be worse than either alone.
 
-Currently hand-written: `tone_curve` (a curve widget over five interpolated
-points), `colour_mixer` (thirty-six faceted parameters from twelve computed hue
-bands). `vignetting` is hand-written too but is not in the develop chain — it
+Currently hand-written: `tone_curve` (one widget over four curves of five
+interpolated points — master, red, green, blue — each reaching the shader only
+when it has been moved), `colour_mixer` (thirty-six faceted parameters from
+twelve computed hue bands). `vignetting` is hand-written too but is not in the develop chain — it
 carries lens-profile coefficients that are not parameters. `distortion` and
 `aberration` are `Warp`s rather than operations: they rewrite coordinates
 before sampling rather than transforming a colour after it.

core/dr-pipeline/ops/tone_curve.yaml

@@ -16,13 +16,26 @@ attributes: [tone, colour]
 rust: ToneCurve
 
 why_rust: |
-  Five control points presented as one curve widget, with an interpolator and
-  a monotonicity guarantee behind it. Its neutral is a *relationship* between
-  parameters rather than a set of values — the identity diagonal — which is
-  not something the declarative `active:` rule can express, and its
-  `presentation()` spans parameters rather than describing one.
+  Four curves — master, red, green, blue — of five control points each,
+  presented as one widget, with an interpolator and a monotonicity guarantee
+  behind them. Its neutral is a *relationship* between parameters rather than
+  a set of values — the identity diagonal, on every channel — which is not
+  something the declarative `active:` rule can express; its `presentation()`
+  spans forty parameters rather than describing one; and its fragment is
+  *assembled* rather than written, because each curve reaches the shader only
+  when it has been moved off the diagonal. A declared node's `wgsl:` is one
+  fixed block of text, which is the right shape for nearly everything here and
+  the wrong one for a node whose cost has to follow what the photographer
+  actually touched.
 
 placement: |
   After the fixed-weight region controls, so the curve is the final word on
   tone: a photographer reaches for it to fix what those controls could not
   place exactly.
+
+  Within the node, the master curve runs before the per-channel ones. Both
+  orders are visibly different images and the reasons for this one are written
+  out in `src/ops/curve.rs`: the master is tonal and hue-preserving, the
+  per-channel curves are the chromatic grade over the tones it produced, and a
+  point placed on a channel curve should act on the tone the photographer can
+  see rather than on the one the master is about to move.