WebGL2 / Windows ANGLE: StandardFragment cold linkProgram (~5.8-6.1s) vs StandardLeanFragment (~2.0-2.1s) and TODO(lean-lighting-pruning) #539

Hi! While profiling WebGL2 first-frame stalls on Windows Chrome (ANGLE Direct3D11 vs_5_0 ps_5_0, RTX 3060 Laptop GPU, disk shader cache disabled), compiling the upstream OpenGL ES StandardFragment took 5786.8-6116.5 ms in linkProgram (7769.7 ms on initial process startup) compared to 1995.2-2585.6 ms for StandardLeanFragment.

Because Lighting.allowsLeanShading currently drops back from lean shading to the full uber-shader as soon as a scene enables any single feature (such as SSAO, one irradiance field, or environment cross-fading), scenes that only use a small subset of lighting features still pay the full ~5.8-6.1 s Windows ANGLE fxc link cost per variant instead of ~2.0-2.1 s.

I noticed material.dart has TODO(lean-lighting-pruning) for pruning unneeded variants via build hook user-defines, and fmat_emitter.dart already separates FLUTTER_SCENE_SKIP_SSAO, FLUTTER_SCENE_SKIP_SHADOWS, and FLUTTER_SCENE_CUSTOM_AMBIENT without inflating base.shaderbundle.

Before attempting any PR, I wanted to ask what architecture direction you prefer for addressing this:

1. Extending build-hook user-defines (continuing TODO(lean-lighting-pruning)) so apps that statically opt out of unused features can strip them from the compiled lit bundle without growing the default .shaderbundle permutations.
2. Relying primarily on lazy/background pipeline compilation rather than additional compile-time feature permutations.

Happy to help test or contribute once the preferred direction is clear.