Lumen follow-up: multi-cascade SDF clipmap

[proggeramlug]

Ticket 014 V2 landed a single-cascade 64³ SDF clipmap that camera-follows at 40 m extent with voxel-snapped origin (V5). The ticket's original plan called for 4 cascades at 2 m / 8 m / 32 m / 128 m half-widths, with per-cascade sparse brick allocation. In practice, V14's 3-cascade WSRC covers the long-range bounce and the single SDF clipmap covers the near sphere-trace, so the quality gap didn't force multi-cascade SDF.

When to do this

• If sphere-trace noise / missed-hit streaking appears on scenes larger than Sponza where the 40 m clipmap can't reach far walls.
• If a scene has interiors where fine detail (< 1 m) matters — V2's 40 m / 64³ = 0.625 m cell is too coarse for rooms with < 2 m features.

Scope

• Per-cascade SDF texture (4 × 64³ R32Float = 4 MB).
• Sparse brick allocator (original plan said "start dense per cascade and only sparsify if VRAM pressure demands it" — so dense first, ~4 MB is fine).
• Per-cascade bake dispatch with different extents.
• Sphere-trace shader: pick the finest cascade containing the current step position; fall through to coarser cascades as the ray advances.
• Camera-follow + snap per cascade at its own voxel size.

Files likely to change

• native/shared/src/renderer/formats.rs — cascade-array SDF textures
• native/shared/src/renderer/shaders.rs — SDF_BAKE_WGSL dispatched per cascade; SSGI_PROBE_TRACE_SDF_WGSL sphere-trace updated to pick cascade inline
• native/shared/src/renderer/mod.rs — per-cascade state, invalidation, bake loop (mirror the V13 WSRC multi-cascade code)

See docs/perf/014-lumen-mesh-sdfs.md §V15 closure.