Render COG colormaps client-side

[slesaad]

Closes #296.

Why

The ramp picker asked a tile server both for the list of ramps and for every swatch's colours. Two consequences:

• A layer rendered client-side could not offer a colormap at all without a tile server running — the one layer type that needs no server was the one blocked by its absence. On a deployment without TiTiler the control read "Color ramps are unavailable".
• When a service did answer, the picker offered ramps that layer cannot paint. Picking one rendered the fallback ramp instead, silently, because normalizeColormapName resolves an unknown name to viridis.

What changed

localColormaps becomes the single source of ramps the app can paint itself. colormapLUT's name resolution moves there and it re-imports it, so the GPU lookup table is unchanged; what is new is being able to ask whether a ramp exists rather than only what it falls back to. Swatch and render now derive from one evaluator, so they cannot disagree.

A layer's ramps come from whatever paints it. cogCapabilitiesFor already worked out which renderer that is and dropped the answer; it now returns it, and the adapter hands the local table only to a layer this renderer paints — for which it is then the whole ramp vocabulary. A tile-server rendered layer is withheld it and keeps resolving both list and colours from its service, exactly as before.

So nothing changes for tile-server layers. The diff is: client-side layers stop needing a server.

The ramps reach the picker as data on CogData, alongside the existing titilerUrl, so LayerManager/lib keeps importing nothing but React and d3. Presence of the table is what says which renderer owns the layer, so that is decided in one place rather than carried as a separate flag through the UI.

Why not use the local ramps for tile-server layers too

An earlier revision did, on the reasoning that both sides derive from matplotlib. Measured against a live service they do agree — every continuous ramp within 1/255 per channel, balance and dark2 byte-identical, qualitative ramps matching band-for-band bar 2–4 boundary pixels of 256.

But agreeing today is not being the same source. A deployment can register a ramp under a standard name, and a version bump can move one; either way the swatch would misrepresent the tiles while looking correct. Keeping each layer's ramps sourced from its own renderer makes that class of drift impossible rather than merely unlikely.

Two fixes that fell out

• Rescale inputs populate. Min/Max rendered blank on a client-side layer because the popover failed to initialise when the colormap request died. Fixing the request fixed the inputs.
• Sampling matches the render. Qualitative ramps (Accent, Set1, the Paired family) were being emitted at their palette length, which a CSS gradient blends smoothly between — while both the GPU lookup table and a tiling service hold each colour for an equal run across 256 entries. All ramps now sample the lookup table's 256 points, and the spec asserts a swatch equals the LUT sample for sample.

Verification

93 test files / 1449 tests pass (up from 92 / 1425); tsc --noEmit clean; LayerManager/lib still imports only react, react-dom, d3.

Verified live against a deck.gl mission whose COG layer has no titilerUrl configured at all: legend swatch renders, the full ramp list renders with swatches, switching a ramp applies instantly, and the network panel records zero /colorMaps requests — only the COG's own range GETs.

🤖 Generated with Claude Code