Golden baselines

Golden baselines live in core/tests/golden/*.png and are ordinary PNGs (viewable in the repo / PR diffs). To regenerate them after an intended visual change:

RLX_BLESS=1 cargo test -p rlx-core --test golden
RLX_BLESS=1 cargo test -p rlx-core --test composite     # the post-stage baselines
RLX_BLESS=1 cargo test -p rlx-core --test line_joints   # the joined-polyline baseline

Only the first of those owns the per-SystemKind roster. Every composite_*.png belongs to the composite test and line_joint_zigzag.png to line_joints; blessing by binary is what keeps the scopes from rewriting each other. line_joints additionally refuses to bless at all while its local-minimum claim is failing, so a reopened notch cannot be baselined in. core/tests/feedback.rs is deliberately absent from that list: it pins no baseline at all — see Asserting that something moved.

Eyeball the regenerated PNGs before committing — the first baseline is easy to enshrine wrong. The compare tolerates minor cross-GPU rasterization drift; a genuine change exceeds it.

Eyeballing the baseline is not enough on its own, and Plan 0045 is the record of why. The whole suite captures on WARP, which is documented to hand a pipeline another live pipeline’s resources (ADR-0021 / Plan 0020, the tonemap in Phase 3, the bloom blur in Phase 4). A mis-rendered frame at these capture sizes can look entirely plausible: Phase 4’s bloom halo was 2:1 elongated in one draft and smeared into a column of copies in another, and the 160x100 baseline looked like a reasonable glow under both. Render the same fixture on the hardware adapter at a size large enough to see it (shot uses the default adapter, so cargo run -p standalone --example shot -- --preset-file <fixture> --size 512x512 is the check) and confirm the two adapters agree before blessing. Where they disagree, the hardware one is right and the baseline is about to enshrine a driver bug.