Fix: replace fixed comps with comps calculation

[yilin0518]

Objective

• Fix a safe-API soundness issue in the bevy_image::universal.rs: universal image saver CompressedImageSaverUniversal.
• CompressedImageSaverUniversal::save called source_image.init(data, size.x, size.y, 4) with the channel count hardcoded to 4 for every input image, regardless of its TextureFormat. basis-universal's image::init reads exactly width * height * comps bytes from the source buffer, so for any format whose pixel size is not 4 bytes this is an out-of-bounds read. For example, a 1×1 R8Unorm image (1 byte of data) causes the encoder to read 4 bytes — a 3-byte overread per pixel, reachable entirely through safe code (Image::new + CompressedImageSaver::save). Larger images amplify the overread proportionally (e.g. a 4096×4096 R8Unorm image overreads by ~48 MiB). Affected formats include every non-4-byte-per-pixel uncompressed format: R8* (1 B/px), Rg8* (2 B/px), R16* (2 B/px), etc.

Solution

• Calculate comps (the channel count source_image reads per pixel) according to the image's TextureFormat instead of hardcoding 4. source_image.init is byte-oriented (each comps is one u8 channel), so only 8-bit-per-channel uncompressed formats can be fed correctly:
  • R8{Unorm,Snorm,Uint,Sint} → comps = 1
  • Rg8{Unorm,Snorm,Uint,Sint} → comps = 2
  • Rgba8{Unorm,UnormSrgb,Snorm,Uint,Sint} → comps = 4
• All other formats are rejected with the existing CompressedImageSaverError::UnsupportedFormat.
• The buggy source_image.init(data, size.x, size.y, 4) becomes source_image.init(data, size.x, size.y, comps).

Additional possible soundness issue

• Because Image::data is a public field and Image::new's length check is only a debug_assert_eq! (skipped in release), a safe-constructed Image can still have data shorter than its declared size×format, which would let init overread even with the correct comps. I don't know whether this is a intentional design to reduce check in release mode, but if not I can provide a new PR to fix it.

Testing

I'm trying to build a PoC to prove that it did read out-of-bounds memory, and I use miri to detect this UB. But Miri don't support FFI, so I can't prove this is a true Bug.

[alice-i-cecile]

More descriptive variable name please :)

[alice-i-cecile]

Can we add a regression test for this? This is subtle and pretty high severity, so I would like both comments and automated testing to help protect us.

API redesign would be even better but I've been fought on making Image more type-safe before :p

[yilin0518]

I've redesigned the implementation and added two tests(One test used to test those supported format and the other test unsupported format). However, the tests have a limitation: I can't verify whether out-of-bounds reads have actually been eliminated, since the real pixel-reading logic happens inside C++. My Rust-side tests can only check whether save() succeeds or the format is correctly rejected — and I can't use Miri to detect out-of-bounds reading.

I'm also not fully confident that my classification of "formats that can't be handled correctly and should be rejected" is accurate. I'd appreciate your suggestion about this PR.