feat(render3d): 23.3 - a .dds beside a .png is uploaded BC-compressed with its whole mip chain

The device's textureCompressionBC is asked for and remembered (gvk_has_bc). tex_load_ex prefers a
DX10 .dds with the full chain beside the .png (not for an edge-padded cut-out atlas):
texture_dds.ludic reads BC7 / BC5 / BC4, gpu_tex_compressed makes the image with every level and
no colour-attachment use (a compressed image is only sampled and copied into), and
gvk_tex_upload_blocks copies each level's blocks from one staging buffer. A colour map is BC7
sampled as sRGB, a data map BC7 read as it is. examples/rendering/bc.ludic holds it, in the suite;
ludic.lab's plate carries its .dds (its three shots render at 56-60 dB against the .png's).

ludic-dev test 307/307, no Vulkan SDK in the environment.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

changes/render3d-bc-textures.md

@@ -0,0 +1,11 @@
+bump: minor
+type: feature
+**A texture with a `.dds` beside its `.png` goes to the GPU BC-compressed, its mips included.**
+`tex_load` (and everything built on it: glTF materials, the terrain's materials, ludic.ui's
+pictures) looks for `<name>.dds` when the device has `textureCompressionBC` - every desktop GPU,
+Apple silicon through MoltenVK too - and uploads its blocks as they are: BC7 (colour in sRGB,
+or data read as it is), BC5 or BC4, a quarter of RGBA8 or less in video memory, no decoding and
+no mipmapping on the load. Only a DX10 `.dds` carrying the whole chain to 1x1 is taken; anything
+else is reported and the `.png` is used, as it is for a cut-out atlas (padded from the `.png`).
+`gpu_tex_compressed` and `R3D_BC7` / `R3D_BC7_SRGB` / `R3D_BC5` / `R3D_BC4` are the backend's
+entry; `examples/rendering/bc.ludic` is the check, and ludic.lab's plate carries its `.dds`.