Route POD music and fill the live race HUD panels

The user reported a persistent sound beginning with the race and transparent lower HUD panels. The default Rust launch now opens target/pod/cd/POD2_0.CUE for music when it reads target/pod/disc/DATA; a caller-supplied --image takes precedence. A one-lap live race completed with both the effects and CD streams written to raw dumps. This proves both streams are produced; it does not identify the sound the user hears or establish sample-for-sample parity. A fresh POD race recording with separated streams is still needed to find the loop.

The race layout parser now retains each HABI element's option lines. Kind 2 draws three damage bars from the car's grouped body-part damage; kind 4 projects the racers into the lower right radar; kind 5 draws the recorded damage icons. The call sites are the POD HABI handlers in FUN_0047e098, FUN_0047f8c0 and FUN_0047e980. The bars summarize parts because the live snapshot does not expose POD's three gauge values, and the radar uses a floating-point approximation to POD's fixed-point projection. These differences are marked in code. The upper-right inset and kind 6 standings gaps remain unported.

Un-POD's live race on Beltane.BL3 from target/pod/disc/DATA, at pass 6,000. The lower-left damage bars and lower-right radar now draw; the upper-right inset is still blank.

cargo test --release --workspace, cargo fmt --all -- --check, the deviations check, and npm --prefix site run build pass. The live one-lap autopilot race reached results. The comments cleanup is continuing separately across Rust source; no audio parity claim is made until the original race can be recorded and compared.