WebGPU: copyFramebufferToTexture reuses timestampWrites after splitting a render pass #34697

Description

With WebGPURenderer({ trackTimestamp: true }), a render pass that calls copyFramebufferToTexture() midway reports only its last segment's GPU time.

In r184, WebGPUBackend.copyFramebufferToTexture() ends the active pass, copies, then resumes it with encoder.beginRenderPass(descriptor) using the same descriptor. That descriptor still contains the original timestampWrites indices. The resumed pass overwrites the first segment's begin timestamp. The query pool then resolves a duration from the resumed begin to the final end, omitting everything before the copy.

Source: WebGPUBackend.js, copyFramebufferToTexture and WebGPUTimestampQueryPool.js.

Reproduction

1. Enable trackTimestamp on a WebGPU renderer.
2. Render an opaque scene, then a transparent material sampling viewportLinearDepth (which triggers ViewportTextureNode.updateBefore and a framebuffer copy inside the scene-colour pass).
3. Resolve render timestamps and compare the scene pass to the same scene without the mid-pass copy, or instrument backend.copyFramebufferToTexture and inspect backend.get(renderContext).currentPass and descriptor.timestampWrites.

On Chrome 153 / Windows / NVIDIA RTX 5070 Ti Laptop GPU, the copy occurred every frame on an active scene-colour pass with timestamp writes. At a 1254×614 CSS viewport (pixel ratio 1.5), the scene pass was reported near 0 ms. Allocating a new query pair for the resumed segment and summing both segments measured roughly 1.7 ms for the same pass in a 41-frame window. The original opaque segment was about 1.7 ms; the transparent tail was below one 0.065536 ms timer step.

Expected behavior

Each segment should receive distinct timestamp indices, and the renderer's pass total should sum those segment durations. The normal render output is unaffected; this concerns GPU timing accuracy.