fix(milliquas): disable colour K-correction that clamped quasars to blue

[rulkens]

Problem

Every Milliquas quasar rendered as the same pure blue (read by the galaxy colormap as "blue star-forming").

Root cause

pickColourIndex applies a redshift K-correction restCI = observedCI − kPerZ·z, clamped to [0, 2], where the blue→white→red ramp spans only 2.0. Milliquas's colourSpec used kPerZ: 0.5, and quasar redshifts run z ≈ 1–7, so the correction subtracted 0.5–3.5 ramp units — more than the observed B−R colour of nearly every quasar. The result clamped the whole catalog to the t=0 blue floor regardless of its real colour.

Empirical check against pickColourIndex (same colour, varying z):

B−R	z	ramp t
1.07	0.5	0.820
1.07	1.5	0.320
1.07	3.0	0.000
0.50	2.0	0.000

The same galaxy collapses from t=0.82 to t=0.00 purely by moving it to higher z. kPerZ=0.5 was tuned for low-z galaxy surveys (z≲0.1, negligible correction); applied to a quasar catalog it becomes the dominant term.

Fix

Set kPerZ: 0 for Milliquas so observed B−R maps straight to the ramp and the genuine blue→red AGN spread survives. A redshift-aware quasar correction belongs in a dedicated bias-correction subsystem with its own QLF, not bolted onto the galaxy ramp.

Note: the catalog still skews blue after this change — quasars genuinely are blue. A follow-up will look at giving AGN their own colormap rather than reusing the galaxy star-forming↔elliptical ramp (the deeper semantic mismatch).

Verification

• npm run typecheck clean
• colourIndex + buildPointInterleavedBuffer tests pass (17)
• Colour-index is baked at runtime in the browser, so this takes effect on HMR — no .bin rebuild / R2 re-sync needed.

🤖 Generated with Claude Code