supportsRenderToMip property

True, and what it turns on is reflection probes.

The false this used to be was honest when it was written and had stopped being so. It was written beside a createCubeRenderTarget that answered null: a probe needs a cube to draw six views into and a chain to convolve them down, ReflectionProbeNode.supportedOn asks for both, and answering yes to the second while the first was missing would have handed the renderer a probe and got a crash where a skip belonged. The cube arrived later — the conformance suite would not let supportsCubeTextures promise a face a pass could name and then hand back nothing — and this line stayed false, which by then described no missing work at all. A refusal that outlives its reason is worse than the gap it once guarded, because nobody goes looking behind it.

There was nothing left to build. The chain a probe wants is not a generateMipmap — this API has none, and the engine never asks a device for one. Renderer._prefilterProbe writes every level itself, as an ordinary full-screen pass whose colour target names a face and a level, and on this backend both of those are one mechanism: baseArrayLayer picks the face and baseMipLevel picks the level on a plain 2D view, which WebGpuTexture.attachmentView has always made. The pass's initial viewport covers the level rather than the texture, because WebGPU takes it from the view's own size, so §7.2's last rule needs no arithmetic here either.

What said so is the picture rather than the reading: probe-car records through this backend and lands on Impeller's reference at nought of a hundred and seventy-two thousand eight hundred pixels, worst channel zero. The two conformance checks this gates — the face-and-level clear and the viewport that covers the level — declined themselves while it was false and now run whole, and test/reflection_probe_test.dart asks the question the capability actually promises: that a mirror ball between a red wall and a blue one shows each on its own side.