Nonsensical texture format capabilities

[inner-daemons]

Description
See #8653 and the CI for it.
Related: #8594

A bunch of texture formats report that they support multisampling but not being a render attachment, which doesn't make sense and you aren't allowed to actually create a texture of this kind. The following is a list I found in the CI with these issues:

• Rgb9e5Ufloat on Vulkan (llvmpipe)

Metal (local):

Nonsensical capabilities: the following formats support multisampling but not being render attachments: [
        R16Unorm,
        R16Snorm,
        Rg16Unorm,
        Rg16Snorm,
        Rgba16Unorm,
        Rgba16Snorm,
    ]

Additionally, GLES on llvmpipe on CI runs into the following, suggesting that features are misreported:

Creating texture with format R32Float and caps TextureFormatFeatures { allowed_usages: TextureUsages(COPY_SRC | COPY_DST | TEXTURE_BINDING | RENDER_ATTACHMENT), flags: TextureFormatFeatureFlags(MULTISAMPLE_X4 | STORAGE_READ_ONLY | STORAGE_WRITE_ONLY | STORAGE_READ_WRITE) }
    [2025-12-04T06:06:17Z ERROR wgpu::backend::wgpu_core] Handling wgpu errors as fatal by default

    thread '<unnamed>' panicked at wgpu/src/backend/wgpu_core.rs:1606:26:
    wgpu error: Validation Error

    Caused by:
      In Device::create_texture
        Format R32Float does not support multisampling

Repro steps
Checkout #8653

Expected vs observed behavior
These issues shouldn't be appearing

Extra materials

Platform
Literally every platform and backend

[inner-daemons]

Update to Rg11b10Ufloat: this seems to have use as a render target gated behind a feature