Un-POD now draws the measured horizon panorama

Un-POD's race background already built the horizon geometry through the measured build_horizon routine. It then sampled the panorama with a simple affine helper. The Rust background now passes the builder's span-list block to POD's measured draw_horizon pass, which dispatches each row to span_horizon. The panorama uses the track's own page and its shade row 0xe0; texel zero stays transparent so clouds and the clear remain visible through it.

The race view after 400 release-probe passes on Beltane. It is not a same-camera comparison with WINPOD.EXE.

The builder creates clipped screen spans; the measured drawer samples the track panorama for each span.

The frame order stays clouds, sun marker, horizon, then world faces. The pod-render path draws the flare later only if the marker survives the horizon and world. The app wiring follows POD's draw_frame_views order, so the connection is inferred even though the builder, pass and span pixels are measured against POD 2.8.

Verification passed: all 19 Un-POD binary tests, the two measured horizon tests (4,000 span lists and 400 pass blocks), a WebAssembly compile, and a 400-pass optimized race probe. The application still uses a stand-in camera and an empty world coverage mask. This pass improves the horizon texture mapping but does not establish whole-frame parity or settle the missing roof and grey texture sections.

The remaining textured-face path is clearer now. The app sends every textured triangle through the perspective 0x60 drawer, while POD also has an affine fan path for some face flags. The format reader currently discards a trailing flags word, and the mapping from disk metadata to POD's runtime face kind still needs tracing. A same-camera capture is needed before attributing the roof gaps to that path. See the renderer notes and the checklist.