WebGPURenderer: Skip resolving anti-aliasing twice

[sunag]

Description

While doing the PR #31730 I noticed anti-aliasing is being resolved twice: once in FrameBufferTarget for applying output color-space conversion and tone mapping, and again during scene rendering. The renderer will now skip resolving anti-aliasing when applying color-space output and tone mapping, keeping only in the rendering of the scene.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	338.24 79.14	338.24 79.14	+0 B +0 B
WebGPU	583.7 161.27	584.36 161.47	+664 B +193 B
WebGPU Nodes	582.3 161.03	582.97 161.22	+664 B +193 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	469.7 113.74	469.7 113.74	+0 B +0 B
WebGPU	653.06 176.75	653.71 176.96	+651 B +214 B
WebGPU Nodes	607.17 165.93	607.82 166.14	+651 B +215 B

[Mugen87]

Would you be okay if we target r181 with this PR? The current dev version is quite stable and I would prefer to not apply deeper refactorings shortly for release.

The additional MSAA for the single full-screen quad should be no huge performance waste.

[Mugen87]

Did some integration testing today for r181 and noticed a regression when dynamically switching from PostProcessing.render() to WebGPURenderer.render(). The regression is introduced with this PR since reverting fixes the issue. Below example can be used for reproduction by toggling the effect with the GUI:

https://rawcdn.githack.com/mrdoob/three.js/dev/examples/webgpu_postprocessing_sobel.html

The screen becomes black and the following WebGPU warnings are logged:

190Cannot set [TextureView of Texture "IOSurface(RasterRead|DisplayRead|Scanout|WebgpuRead|WebgpuSwapChainTexture|WebgpuWrite)"] as a resolve target when the color attachment [TextureView of Texture "IOSurface(RasterRead|DisplayRead|Scanout|WebgpuRead|WebgpuSwapChainTexture|WebgpuWrite)"] has a sample count of 1.
While validating colorAttachments[0].
While encoding [CommandEncoder "renderContext_16"].BeginRenderPass([RenderPassDescriptor]).
While finishing [CommandEncoder "renderContext_16"].

It seems, it does not happen with the WebGL backend.