docs: make the intensity explanation order-agnostic

Both pages explained intensity's independence by saying details and
effects are applied after the u_intensity mix. The conclusion was right
but the mechanism was wrong for several families.

Verified in the shader: applyCrtWarp runs on the uv before sampling;
sampleMedia itself carries pixelate, chromaBleed and the tape family;
sampleChromaticMedia and applyDigitalGlitch shape sampleColor — all
before the mix at runtime/colorGrading.ts:1234. Only grain,
filmArtifacts, monoScreen, engraving, crosshatch, halftone, twoInkPrint,
bloom, scanlines and vignette run after it.

Pre-mix effects are already present on both sides of
mix(sampleColor.rgb, applyColorGrade(sampleColor.rgb), u_intensity), so
intensity does not scale them either. Both pages now say details and
effects sit outside the mix — some before, some after — without making
the ordering the reason.

Reported by miguel-heygen.

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

Author: vanceingalls

docs/guides/color-grading.mdx

@@ -271,9 +271,12 @@ Two things this list does **not** give you:
 - **`--hf-color-grading-intensity` scales the primary grade only.** The shader
   mixes between the ungraded sample and the graded one at that value, so it
   ramps `adjust`, `wheels`, `curves`, `hueCurves`, `secondaries` and the LUT.
-  It does **not** touch `details` or `effects` — grain, vignette, halftone,
-  twoInkPrint, bloom, the tape and CRT families are all applied *after* that
-  mix. So it is not a master "ramp the whole look" dial when the look is
+  `details` and `effects` sit outside that mix entirely and it scales neither.
+  Some of them shape the sampled media *before* the mix — CRT warp, blur,
+  Kuwahara, pixelate, the tape family, chromatic aberration, digital glitch —
+  and so are already present on both sides of it. Others run *after* it —
+  grain, halftone, bloom, scanlines, vignette. Either way intensity does not
+  reach them, so it is not a master "ramp the whole look" dial when the look is
   effect-based; animate the specific effect instead.
 - **Every other property — `halftone`, `twoInkPrint`, `tapeDamage`, hue curves,
   secondaries — has no custom property**, so it cannot be tweened this way.

docs/prompting/color-grading.mdx

@@ -159,7 +159,7 @@ Nine properties expose a CSS custom property and tween directly — `ascii`, `bl
 
 Two caveats worth knowing before you promise a client a ramp:
 
-- **`--hf-color-grading-intensity` scales the primary grade only** — `adjust`, `wheels`, `curves`, `hueCurves`, `secondaries` and the LUT. It does *not* scale `details` or `effects`, which are applied after that mix, so it will not ramp grain, halftone, bloom or the tape and CRT families. Reach for the specific effect instead of treating it as a master dial.
+- **`--hf-color-grading-intensity` scales the primary grade only** — `adjust`, `wheels`, `curves`, `hueCurves`, `secondaries` and the LUT. `details` and `effects` sit outside that mix and it scales neither: some shape the sampled media before it, others run after it. So it will not ramp grain, halftone, bloom, or the tape and CRT families. Reach for the specific effect instead of treating it as a master dial.
 - **Everything else has no custom property.** Some of those can still be animated by rewriting the `data-color-grading` payload from the timeline, and some cannot — the verified list of which is which lives in the guide's [Animating a Grade](/guides/color-grading#animating-a-grade), so it only has to be maintained in one place. Measure the effect you intend to animate before you promise a ramp, and fall back to a static treatment if it does not move.
 
 ## Next steps