Function validateEffectRenderPass

Checks an EffectRenderPass against §85, throwing a RangeError on the first violation and returning nothing when the pass is well formed.

Called by RenderGraph.addPass for every effect pass, which is where an application normally meets it; exported because an application that hand -writes renderer.renderEffect has no graph to do it (module header).

Five things are checked, and deliberately nothing else:

1. source really is a render-target texture — the marker guard, not the type, because a JavaScript caller can hand over anything and a backend that met a plain Texture here would silently draw a black screen;
2. effect.kind is a member of the closed union — a value TypeScript would have rejected, arriving from JSON or from JavaScript;
3. each declared grading coefficient is finite and non-negative — a NaN reaching a uniform3fv produces an entire black frame with no error anywhere, which is the failure this function exists to prevent;
4. an output-transform pass reads linear and writes sRGB — §60a's colour-space metadata, checked where a double encode is still a wiring mistake rather than a washed-out frame;
5. rect, when named, is finite and non-negative in width/height — a NaN scissor is a GL error and a negative extent is clamped-to-empty at draw time; refusing here keeps the mistake at setup.

Not checked: whether the source is disposed, and whether it is the same surface as target. Both are frame-time facts (a target may be disposed long after the pass was added), both are already handled where they belong — RenderGraph.validate reports the second statically as "feedback" and every backend refuses both at draw time (§83, R-4).