fix: specify `rgba8unorm` render target for `webgpu:api,operation,labels:wrappers_do_not_share_labels:*`

[ErichDonGubler]

Issue: #3754

---

Requirements for PR author:

• [x] All missing test coverage is tracked with "TODO" or .unimplemented().
• [x] New helpers are /** documented */ and new helper files are found in helper_index.txt.
• [x] Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)
• [x] Test have be tested with compatibility mode validation enabled and behave as expected. (If not passing, explain above.)

Requirements for reviewer sign-off:

• [x] Tests are properly located in the test tree.
• [x] Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
• [x] Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs. I'm actually going to punt missing coverage to #3755.
• [x] Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

[ErichDonGubler]

Alternatively, we could make the diff a bit smaller by using a depth-stencil attachment instead:

@@ -265,7 +265,14 @@ g.test('wrappers_do_not_share_labels')
       layout: 'auto',
       vertex: {
         module,
         entryPoint: 'main',
       },
+      // Specify a depth-stencil attachment so we have at least one render target. Not relevant to
+      // this test.
+      depthStencil: {
+        format: 'depth16unorm',
+        depthWriteEnabled: true,
+        depthCompare: 'equal',
+      },
     });
     const layout1 = pipeline.getBindGroupLayout(0);

…but the rgba8unorm color attachment seems like established precedent elsewhere.

[kainino0x]

The GitHub settings require the PR branch to be up-to-date with main before landing (because we have some things that are very prone to merge conflicts). Could you merge with main? Then once checks pass again, auto-merge should accept it.

[ErichDonGubler]

Rebased!

CI's build job appears to be still running (getting up to ~10m now), but previous runs are significantly shorter (i.e., the run in the pre-rebased branch tip ran in ~3.5m, main's current tip reports a similar runtime for its CI). Also, the run in question seems to have not terminated still, despite all steps being reported as completed? 🤔 Is this a CI platform bug, maybe? See also the below screenshot.

ETA: Attempting to resolve this with a job restart.

[kainino0x]

Weird stuff like that happens from time to time. It seems to have eventually resolved itself though!

[kainino0x]

Or rather, it seems you resolved it by retrying :)