fix(render): shadow-gated-off receiver frames light from the authored sun again (Campaign VM VM6 review 5)

Round 4 (eec95535) fixed wind but introduced a new lighting bug: the
receiver VERTEX shaders source the sun direction from the shadow block,
not only the shadow visibility term. mesh_atmospheric.vert's
accumulateLights read uShadowLightDirectionAndSource unconditionally for
every directional light; terrain_atmospheric.vert did the same for its
single sun term. Round 4's PublishDisabledReceiverBinding writes
direction (0,0,1) into that block on every shadow-gated-off frame (user
sun-shadow-strength 0 in daylight, indoor/portal cover, night), so every
such frame was lighting outdoor terrain and objects from straight
overhead instead of the authored sun. Publishing the environment's real
direction would not have restored parity either -- the celestial shadow
source direction (sun/moon disc) is not the authored light direction.

F1 (BLOCKER): fixed in the shaders themselves, exact parity with the
plain pipeline. Both receiver verts now branch on the same flag bit
acdreamDirectionalShadowVisibility already reads
((uShadowTextureAndFlags.w & 1u) == 0u) and, when clear, use the EXACT
plain-pipeline expression instead of the shadow block's direction:
-uLights[i].dirAndRange.xyz in mesh_atmospheric.vert (matching
mesh_modern.vert, hoisted out of the light loop as a uniform branch);
-uLights[0].dirAndRange.xyz in terrain_atmospheric.vert (matching
terrain_modern.vert's sunDir/-sunDir form). The (0,0,1) word in the
disabled block stays as the documented normalize()-cannot-NaN guard; its
comment now says so explicitly since it is no longer read as a light
direction when the flag is clear.

F2: RenderPrepared's cascadeCount == 0 return is a third bufferless-
disabled path reachable from a frame that already passed Render's own
two gates (the cascade fitter can still find zero usable cascades) --
publishes the same disabled binding now, via the same
PublishDisabledReceiverBinding helper (re-signatured to take a bare
AtmosphericFrameBufferBinding so all three call sites -- Render's two
early-outs plus this one -- share it).

F3: removed a stray duplicated " -- Closeout and merge" fragment under
the plan's VM7 heading.

F4: corrected the false "the flag bit makes it numerically the plain
lighting sum" claim in the plan's round-4 paragraph and in
WbDrawDispatcher.DirectionalShadowReceivers.cs -- the flag bit alone
only fixed the shadow VISIBILITY term (already correct before round 4);
it took both that AND round 5's light-DIRECTION fallback to actually
match the plain pipeline.

T1: extracted Render's gate prologue (environment evaluate -> two
early-outs -> PublishDisabledReceiverBinding) into internal
EvaluateGateAndPublishDisabledBinding(frame, in input, out environment,
out environmentGateTicks), behaviour-preserving, called by Render before
it touches world/terrain -- the ArgumentNullException.ThrowIfNull(world)/
ThrowIfNull(terrain) calls keep their exact position relative to the
gate. No test in this suite constructs a real WbDrawDispatcher +
TerrainModernRenderer pair (still true), so this extraction is what
makes the gate itself testable; two new tests drive it directly with
PlayerInsideCell: true and with ResidentMaximumReachMeters <=
CameraNearMeters, asserting TryGetCurrentFrameBinding true / IsValidFor
false for both.

T2: proves the actual composition WbDrawDispatcher.PipelinesFor and
TerrainModernRenderer both use -- TryGetCurrentFrameBinding feeding
ShouldSelectReceiverPipeline -- selects the receiver pipeline for the
atmospheric world pass once a disabled binding is published, and still
refuses a non-atmospheric pass name.

T3: shader-source guard (same style as AtmosphericPostProcessGraphTests'
existing shader-text tests) pinning that both receiver verts contain the
flag-gated fallback and reference the same uLights expression the plain
verts use, so a future edit that drops the fallback fails this test
instead of only showing up in a pixel capture.

T4: the (0,0,1) test's doc comment and an inline assertion comment now
say the value is a NaN guard, not a light direction.

Regenerated SPIR-V: mesh_atmospheric.vert and terrain_atmospheric.vert
recompiled to different bytes this time (a real code change, not a
comment); manifest updated to match.

Verify: Release build 0 warnings/0 errors. App hermetic-lane filter
6,054/0 failed. Core.Tests 4,695/0 failed. RenderPackValidator 30/30.
Full hermetic-filtered solution: 15,282/0 failed across 15 projects.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/plans/2026-08-22-visualmaster-campaign.md

@@ -82,10 +82,10 @@ single-pass path darkens by ~10 %. Neither explains a scene-wide level.
 | VM3 | F4 — linear-light post stack | **CODE-COMPLETE 2026-08-22** — `87677f9c`, `51178f7c`, closeout; Opus APPROVE; **owner visual gate OWED** (brief below) |
 | VM4 | F5 — overclaiming docs, incl. the reviewer's own | **CLOSED 2026-08-22** |
 | VM5 | F8 — volumetric banding; F7 filed | **CLOSED 2026-08-22** (#421) |
-| VM6 | Foliage wind | automated + **owner visual** |
+| VM6 | Foliage wind | **CODE-COMPLETE 2026-08-23** — `0930c35d`, `39e8408c`, `43e3abed`, `a82959f1`, `fccba839`, `eec95535`; four Opus review rounds (round 3 APPROVE, round 4 narrow re-review of `fccba839`+`eec95535`); pixel proof [note](../research/2026-08-23-vm6-foliage-wind-pixel-proof.md) (13,854 robust wind px vs 19 floor, scenery only); **owner visual gate OWED** (§VM6 Acceptance) |
 | VM7 | Closeout: full gates, register, roadmap, merge | **owner** |
 
-Order is VM2 (done) → VM0 (done) → VM1 (done) → VM4 (done) → VM5 (done) → VM3 (code-complete, gate owed) → VM6 → VM7. VM0 goes first because everything after it is measured
+Order is VM2 (done) → VM0 (done) → VM1 (done) → VM4 (done) → VM5 (done) → VM3 (code-complete, gate owed) → VM6 (code-complete, gate owed) → VM7. VM0 goes first because everything after it is measured
 against the baseline it establishes.
 
 ---
@@ -495,7 +495,7 @@ direction to read, and the register row says so.
   indoors — nothing moves; (6) pack off — nothing moves. The owner's words
   decide; the numbers above are starting points to tune live.
 
-### VM6 outcome (implementation landed 2026-08-22; owner visual gate outstanding)
+### VM6 outcome (implementation landed 2026-08-22; code-complete 2026-08-23 at `eec95535`; owner visual gate outstanding)
 
 Two commits (VM6a shader ABI v2 plumbing, VM6b the feature) shipped the
 design above; a same-day fix-round commit corrected the weather-table key.
@@ -694,13 +694,53 @@ direction `(0,0,1)` so a fragment shader's `normalize()` can never
 produce NaN. `BindDirectionalShadowReceiver` and
 `TerrainModernRenderer`'s shadow-buffer bind now check `Buffer is not
 null` instead of `Enabled`, so this disabled block actually gets bound
-once it is selected. Consequence in one sentence: the built-in pack's
-world pass now always runs the receiver shader; with shadows gated off,
-the shadow block's own flag bit makes its shadow term numerically the
-plain lighting sum, while wind keeps moving correctly.
+once it is selected.
+
+**Review fix round 5 (2026-08-23) correction to the paragraph above:** the
+claim "the flag bit makes it numerically the plain lighting sum" was
+false as written — F1 BLOCKER, found by the reviewer's own offline pixel
+apparatus reading the shader source, not by a repro capture (the disabled
+block's `(0,0,1)` direction differs too little from straight-overhead to
+show up above the apparatus's noise floor at these amplitudes, so the
+mislighting was invisible to that specific test even though it is real).
+Both receiver VERTEX shaders (`mesh_atmospheric.vert`,
+`terrain_atmospheric.vert`) sourced the sun direction used to compute
+`directionalLit`/`vDirectionalLit` from the shadow block's own
+`uShadowLightDirectionAndSource`, unconditionally — not only the
+*visibility* term, which was already correctly flag-gated. Every shadow-
+gated-off frame was lighting outdoor terrain and objects from the
+disabled block's `(0,0,1)` placeholder — straight overhead — regardless
+of the authored sun's actual position. The celestial shadow source
+direction is not the authored light direction either, so publishing it
+instead would not have restored parity. Fixed in the shaders themselves:
+both receiver verts now branch on the SAME flag bit
+(`(uShadowTextureAndFlags.w & 1u) == 0u`) and, when clear, use the EXACT
+plain-pipeline expression (`-uLights[i].dirAndRange.xyz` in
+`mesh_atmospheric.vert`, matching `mesh_modern.vert`;
+`-uLights[0].dirAndRange.xyz` in `terrain_atmospheric.vert`, matching
+`terrain_modern.vert`) instead of the shadow block's direction. Corrected
+statement: with the flag bit clear the receiver shaders take visibility
+1.0 AND fall back to the authored `uLights` direction (round 5), so a
+gated-off frame is numerically the plain pipeline. Wind is unaffected —
+`foliage_wind.glsl` reads only the AtmosphericFrame half of set 3, never
+the shadow block.
+
+**Pixel proof after round 4 (2026-08-23, `eec95535`):** the same
+apparatus that found the defect — High preset, `sun-shadow-strength=0` so
+no shadow term can move, same pinned clock, wind on vs off, two captures per
+arm so the repeat pairs measure the run-to-run floor — gives a robust wind
+mask of **13,854 px** (amplified: strength 2, lean/branch 1 m, flutter
+0.5 m) against a **19 px** floor, and **1,402 px** at the default Clear
+strength; every marked pixel is a treeline tree, hillside tree or shoreline
+bush, and no house, fence, road, lifestone, ground, water or UI pixel moves.
+The first method tried (clock pin 0 s vs 3 s, wind-off pair as the control)
+is recorded as confounded in the note and must not be reused: the treeline
+silhouette carries a bimodal 0-or-~280 px rasterisation churn between runs
+that lands on either side of the subtraction by luck. Tool:
+`tools/vm6/wind-pixel-proof.py`; note:
+`docs/research/2026-08-23-vm6-foliage-wind-pixel-proof.md`.
 
 ## VM7 — Closeout and merge
- — Closeout and merge
 
 - Full gates: `tools/run-release-gate.ps1` (hermetic lanes), the AR
   reference matrix re-run for the changed presets, VM0's masked comparison