[WebGPU-XR][Phase 2] WebGPU projection layer + render target provider

[RaananW]

Part of #18635. Depends on Phase 1.

Phase 2 — WebGPU projection layer + render target provider

Implement the core WebGPU rendering path: render the stereo scene into the projection layer's per-view GPUTextures.

Scope

• Add a WebXRGPUProjectionLayer render-target provider: on each getViewSubImage(layer, view), wrap subImage.colorTexture (and depthStencilTexture when present) via AbstractEngine.wrapWebGPUTexture into an InternalTexture → RenderTargetTexture, applying getViewDescriptor() and viewport.
• Verify the WebGPU engine renders into the externally-provided color+depth GPUTexture per eye (bindFramebuffer/RTT path), rather than the canvas swapchain (getCurrentTexture() must not be used in XR).
• Handle MSAA resolve and per-view texture-view descriptors; wire viewport per eye.

Acceptance

• Correct stereo rendering on Quest Browser with WebGPU (manual verification).
• No regression to non-XR WebGPU rendering.

[RaananW]

Phase 0 follow-up: multiview color/depth array path for the RT-provider seam

Surfaced during Phase 0 PR #18644 (RT-provider split).

The API-agnostic seam WebXRLayerRenderTargetTextureProvider._createRenderTargetTextureInternal(...) introduced in Phase 0 only handles the single-InternalTexture path (color via renderTargetWrapper.setTexture, depth via _depthStencilTexture). It does not cover the multiview array case that the WebGL-specific WebXRWebGLRenderTargetTextureProvider._createRenderTargetTexture(...) still handles via _colorTextureArray / _depthStencilTextureArray.

That's intentional and fine for the Phase 0 WebGL-only seam, but when we wire the WebGPU projection-layer render target provider in this phase, multiview WebGPU XR will need an equivalent array-backed path (or an extension of _createRenderTargetTextureInternal) so multiview foveated rendering works on the GPU backend.

Action for Phase 2: provide a multiview color/depth-array equivalent when building the WebGPU RTT provider.