bugfix(bgfx): Sample the scene composite the right way up on GLES

[githubawn]

The scene composite pass reads the scene render target back to the swapchain with a fullscreen triangle. Render targets are bottom-left origin on GLES and WebGL but top-left on DX11 and Metal, and nothing accounted for that: the vertex shader built one fixed set of texture coordinates, and the backend passed a hardcoded 0 where the flip flag belongs.

So everything that goes through the composite — the whole 3D scene — came out vertically mirrored on those renderers, while the UI, which draws straight to the swapchain, stayed upright. That reads as "the game is upside down but the menus are not".

Fix

Carry the flag in u_postTexelSize.z, sourced from bgfx's originBottomLeft cap, and flip V in the vertex shader when it is set.

Platform impact

DX11 and Metal report originBottomLeft == false and pass 0.0, so the sampled coordinates are identical to before — those backends are byte-for-byte unaffected. The behaviour change is confined to bottom-left-origin renderers, which are the ones that were wrong.

On trunk the composite is gated only on the scene framebuffer being valid, not on render-resolution scaling, so this affects any GLES/WebGL target that has the scene framebuffer active.

Testing

Verified on the Emscripten/WebGL build, where the 3D scene rendered mirrored before the change and correct after. Not runtime-verified on Android GLES or desktop GL — those go through the same cap and should be fixed identically, but a second pair of eyes there would be welcome.

[bobtista]

vs_scene_composite is also linked into the bloom-bright, bloom-blur, SSAO and copy programs (BgfxBackend.cpp:4471-4485), but .z is assigned only in SubmitSceneComposite. SubmitSSAO explicitly writes 0.0f (:3869), and the bloom, blur and copy submits never set this uniform at all — with submit order Bloom → SSAO → Composite (:6070-6072), the bloom passes inherit whatever the previous frame's composite left behind, which is undefined on the first frame. copyProgram feeds both kBgfxSmudgeCopyView (:11925) and kBgfxPointShadowVizView (:3339), whose consumers handle UVs differently.

Let's set the intended value explicitly at every submit that uses this VS, or split out purpose-specific fullscreen vertex shaders, and verify each producer/consumer pair.