Expand visual regression suite and per-profile performance baselines in CI

[leftger]

Goal

Catch visual and performance regressions before release.

Acceptance criteria

• Golden scene matrix expanded
• Perf baselines per profile
• Regression thresholds enforced in CI

[leftger]

Partially addressed by e9c25fd: the golden-image matrix now exists (3 scenes, tolerance-based diff enforced in CI — see #8), but the perf-baseline half of this issue is still open. benches/raster_benchmark.rs exists but is not invoked anywhere in .github/workflows/ci.yml, and the profile-budget matrix (m3/m4/m33/m55) only guards telemetry command counts, not timing/perf baselines — there's no per-profile perf regression threshold enforced yet. Keeping this open, scoped to: wiring the benchmark into CI and adding per-profile perf baselines with enforced thresholds.

[leftger]

Update from 569738e:

• Golden scene matrix expanded — psx_preset added as a 4th canonical scene (tests/golden_images/psx_preset.png), joining solid_cube, gouraud_mesh, doom_preset. All 4 are diffed by the existing tolerance-based gate in test (see Ship golden-image regression tests for canonical scenes #8).
• Per-profile perf baselines — new perf-baseline CI job matrixed over m3/m4/m33/m55 (mirrors the profile-budget pattern), sizing the framebuffer from each profile's ProfileCaps and benchmarking both the float and Q16.16 fixed-point rasterizer paths (benches/raster_benchmark.rs). Along the way, fixed a real bug where the fixed-point path was being dead-code-eliminated (no std::hint::black_box), which had been silently reporting an impossible ~243M kTri/sec.
• Regression thresholds enforced in CI — intentionally still open. Decided against a hard wall-clock gate: shared GitHub-hosted runners are too noisy for a reliable absolute or relative perf threshold (same reasoning that keeps the existing telemetry budget checks count-based rather than timing-based). The new job is report-only, printing perf_baseline profile=... path=... ktri_per_sec=... to the job summary for visibility/trend-watching rather than failing the build.

Remaining scope for this issue: decide on and implement an actual enforcement mechanism for perf regressions (e.g. a self-hosted/dedicated runner with stable timing, or a relative-regression check against a periodically-refreshed committed baseline) if a hard gate is still wanted.