WIP: capture sharpening

Checkpoint committed by the coordinator, not by the authoring agent: the
session hit its API limit mid-task and left this work uncommitted. Committed
so it survives, NOT because it is finished - expect failing tests and
half-applied changes. The agent resumes from here.

core/dr-pipeline/ops/README.md

@@ -211,7 +211,9 @@ 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
+bands), `capture_sharpen` (a separable convolution, which is the other reason a
+node is Rust — see the next section). `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.
@@ -239,6 +241,9 @@ rather than a convenience. A node of this kind:
   each with a WGSL body, its uniforms, and **its kernel radius in render
   pixels**, which the tile scheduler needs and nothing can infer.
 
+`capture_sharpen` is the worked example: two passes, one per axis, and a radius
+converted from source pixels once per render.
+
 The `order:` still belongs here, and still orders the node — among the other
 detail nodes. Detail runs as a group after every point operation, so an `order:`
 that interleaves one with exposure would be a lie the chain cannot tell.