test: use non-square asymmetric textures in coordinate-sensitive tests

[emilk]

Connections

• Related to fix(gles): texture height initialized incorrectly in create_texture #9302

Summary
Use non-square asymmetric textures in tests to catch bugs like the one in #9302. No bugs were caught.

Description

Many GPU tests allocate square textures (width == height). A square texture hides bugs: code that swaps width and height, or that confuses u/v texture coordinates, still produces a passing test because the two dimensions are interchangeable and the contents are often symmetric.

This PR converts the coordinate-sensitive tests — those that write known data, copy regions, render, or sample and then assert on per-coordinate values — to use non-square textures. Where a test asserts on texel contents, the contents are also made asymmetric under transpose, horizontal mirror, and vertical mirror, so a row/column or u/v mix-up changes the bytes and fails the assertion. The most notable content fix is planar_texture's plane-copy test, whose old i as u8 pattern aliased every row identically (vertically symmetric); it now depends on both axes.

Tests converted:

• write_texture: 256×256 → 256×320 (SUBSET_2D/3D, NO_OOB)
• regression/issue_6827: 4×4×4 → 4×5×6 (every axis distinct)
• clip_distances: 256×256 → 256×320, per-pixel asserts recomputed
• planar_texture: 256×256 → 256×320; plane-copy content now depends on both x and y
• zero_init: 256×256 → 256×320 (and half-res planes 128×160)

Dimensions were chosen to keep all existing alignment requirements satisfied: width stays a multiple of COPY_BYTES_PER_ROW_ALIGNMENT (256) so bytes_per_row remains aligned for copy_texture_to_buffer, and NV12/P010 textures keep even dimensions (chroma is half-resolution).

height > width is deliberate: a backend that mistakenly sizes a texture's height from its width (the exact bug fixed in #9302, where GLES create_texture used desc.size.width for the height) then under-allocates, so the full-extent readback or render overruns the real storage and the test fails. With height < width such a backend would over-allocate and every in-bounds access would still return correct data, hiding the bug — which is why the square tests never caught #9302.

Tests that are not coordinate-sensitive (lifecycle, OOM, bounds-validation, 1×1, mip-array, sampler-filtering) were intentionally left unchanged.

Testing

Test-only change. cargo check, cargo clippy, and cargo fmt pass for the wgpu-gpu test target. The converted tests retain their original assertions, recomputed for the new dimensions (e.g. the clip_distances per-pixel checks were recomputed from the shader's y_ndc >= |x_ndc| fill region). The full GPU test suite should be run on CI across backends — in particular on a GL backend, where the height > width choice is what exercises the #9302 regression.

Squash or Rebase?

Single commit; ready to rebase onto trunk as it stands.

Checklist

• I self-reviewed and fully understand this PR.
• WebGPU implementations built with wgpu may be affected behaviorally.
• Validation and feature gates are in place to confine behavioral changes.
• Tests demonstrate the validation and altered logic works.
• CHANGELOG.md entries for the user-facing effects of this change are present.
• The PR is minimal, and doesn't make sense to land as multiple PRs.
• Commits are logically scoped and individually reviewable.
• The PR description has enough context to understand the motivation and solution implemented.

[ErichDonGubler]

Seems like a strict improvement to me! Is it still interesting to add square dimension coverage as, say, follow-up?