Add BC7 (BPTC) DDS texture support

[juliendms]

Description

BC7-encoded DDS files use the modern DX10 FourCC plus a 20-byte
DDS_HEADER_DXT10 extension containing a dxgiFormat field
(98 = BC7_UNORM, 99 = BC7_UNORM_SRGB). The current loader rejects
this header, so BC7 textures cannot be loaded even though the upload
path (glCompressedTexImage2D with GL_COMPRESSED_RGBA_BPTC_UNORM)
already works on any GL 4.2+ driver.

The patch:

• recognises the DX10 FourCC in dds.cpp, reads the 20-byte extension
  and decodes dxgiFormat 97/98/99 (BC7 typeless / UNORM / UNORM_SRGB);
• adds PixelFormat::BC7 and PixelFormat::BC7_sRGBA mapped to
  GL_COMPRESSED_RGBA_BPTC_UNORM / GL_COMPRESSED_SRGB_ALPHA_BPTC_UNORM;
• wires those formats through image.cpp (block size, components, alpha,
  compressed flag) and texture.cpp (internal/external GL format) --
  block geometry is identical to DXT5, so the size math is verbatim;
• probes GL_ARB_texture_compression_bptc in glsupport, mirroring the
  existing EXT_texture_compression_s3tc flag, and refuses BC7 files
  when BPTC is unavailable rather than handing them to the s3tc software
  fallback (which only knows DXT1/3/5).

The CPU-side software decompressor (dds_decompress.cpp) is intentionally
left untouched. BC7 software decoding is non-trivial (8 modes, partition
tables, endpoint encodings) and unnecessary on any modern GL driver.

Tested

Win32 build (VS 2026 / MSVC 19.50 / CMake 4.2), Windows 11, RX 6750 XT,
against several BC7-encoded planet textures (diffuse, specular, cloud,
night-side) up to 16384^2. Existing DXT1/3/5 loading paths verified
unchanged.

Out of scope

• BC7 inside .ctx virtual-texture tilesets -- virtualtex.cpp has its
  own DDS reader path that does not go through LoadDDSImage. I plan on investigating CTX pipeline in the coming weeks.
• BC6H / other DXGI formats -- only BC7 UNORM and UNORM_SRGB are decoded.

Screenshots

IO with all textures in 16k BC7

Earth cloud with 16k BC7

---

Disclaimer: The code in this PR was generated by AI
(Anthropic Claude), then reviewed, built and tested by me before
submission.

[375gnu]

I suppose we should decide about ai contributions.

[juliendms]

I put this PR as draft because although "it works" the current implementation is kind of misleading.

• To render sRGB content (eg. a JPEG texture) encoded in BC7, right now it needs to be encoded as BC7_UNORM to be correctly rendered by Celestia.
• Encoding sRGB content as BC7_UNORM_SRGB renders incorrectly (too dark) because the GPU applies an sRGB-to-linear transformation, but nothing re-encodes it to sRGB for display.
• When Rework sRGB support #2483 is merged, I will be able to wire properly BC7_UNORM and BC7_UNORM_SRGB, and BC7_UNORM_SRGB will properly render sRGB content with the SRGBRendering flag set to true.

TL;DR: PR blocked until #2483 is merged for clean implementation.

[ajtribick]

I suppose we should decide about ai contributions.

Can't speak for anyone else, but reviewing AI output doesn't feel like a good use of my free time.

[juliendms]

• Extended the sRGB→non-sRGB strip table consulted on the upload path with the BC7_sRGBA → BC7 mapping. Without this, a BC7-sRGB-tagged DDS loaded with sRGB rendering disabled would hit the sampler with a hardware sRGB decode applied and no compensating re-encode downstream, rendering one sRGB-curve too dark (see previous comment)
• Extended the merged DX10 header: shared DXGIFormat enum and dispatch helper gain BC7_UNORM = 98 and BC7_UNORM_SRGB = 99.

Results:

Tests: Jupiter is BC7_sRGBA and Io is BC7, both carry sRGB content.

When sRGB is deactivated: BC7 and BC7_sRGBA renders exactly the same.

When sRGB is activated: BC7 expects linear encode, while BC7_sRGBA must be used for sRBG encoded content. Here Jupiter renders as expected, while Io renders incorrectly (as expected, because of incorrect DDS flag).