fix(core): bound the pie-chart label atlas to the device texture limit

[tsenoner]

Closes #457. Prerequisite for #456 — see Ordering below.

What was wrong

The pie-chart label atlas is sized from the renderer's point capacity, so its height silently made gl.MAX_TEXTURE_SIZE the point ceiling. gl.MAX_TEXTURE_SIZE was queried nowhere in the tree, and gl.getError() was called nowhere in any src/.

device MAX_TEXTURE_SIZE	atlas capped at
2048 (the WebGL2 spec floor)	524,288 points
4096	1,048,576 points
8192	2,097,152 points

A device reporting 2048 could not allocate the atlas for the shipped 573,649-protein Swiss-Prot bundle — it needs height 2241. The failure was invisible and permanent: an over-size texImage2D raises GL_INVALID_VALUE, which is not a JS exception, so nothing unwound and the texture was left unallocated — but labelTextureInitialized = true was set regardless, so every later update ran texSubImage2D against storage that never existed. The user saw black pie marks and a clean console.

The 4096 tier looked safe against MAX_POINTS_DIRECT_RENDER = 1_000_000 until the 1.5× geometric growth in planRendererCapacity is accounted for: the constant capped maxPoints but not capacity, so loading 900k then 950k planned 1,350,144 → height 5274 → over the limit at a point count well under a million.

Three more defects found while verifying, none of them in the report

• stage-point.ts wrote labelCounts unclamped while fillLabelColorTexels writes at most MAX_LABELS texels. The shader's count was likewise unclamped, so a point with more than 8 distinct colours read the next protein's texels for its surplus slices — an unrelated protein's colours, presented as this one's data.
• Neither count nor sliceIndex was clamped. atan(+0, x<0) is exactly +PI, so the normalised sweep reaches 1.0 on the middle pixel row of any odd-height sprite and sliceIndex reached count — the same overrun on well-formed points.
• POINT_FRAGMENT_SHADER declared only precision highp float. ES 3.00 defaults fragment int to mediump, whose guaranteed range is 16 bits, so flat in int v_pointIndex and the atlas index derived from it were undefined above 32,767 on any driver honouring the minimum — precisely the low-end hardware this change is about.

What changed

• Geometry is planned against the device, in a new pure GL-free module. Full stride is preferred over a wider texture, so every device at 4096 or above allocates byte-identical geometry to before (2048×2241 at Swiss-Prot). Width widens to 4096/8192 first; only then does stride fall to 4, then 2. The floor is 2 because eat-annotation-overlay requires a two-label cell to render both hues in live and exported markers. Points are never dropped to fit a decoration.
• Capacity is clamped by MAX_POINTS_DIRECT_RENDER, bounding the 1.5× overshoot. This alone rescues every device at 4096+: 1,000,192 points is height 3907. The clamp is floored at the snapped requirement, so it can never starve a larger load.
• gl.getError() once per capacity change, never per frame: after the allocating bufferData (before any texture call, so a buffer failure is not misattributed) and after the atlas texImage2D. Initialised is recorded only on NO_ERROR; a 1×1 placeholder keeps the sampler complete otherwise.
• A new u_labelAtlasCapacity uniform gates the pie branch, so a point outside the atlas paints its dominant colour — never black.
• Reductions reach the user through the existing host-message channel, latched once per reason. The equally silent gamma-pipeline fallback now routes through it too.
• The export path gets the same guarantees: its own probe, the stride inherited from the live view so a figure matches the screen, an error check, and a MAX_DIMENSION that is min(8192, device limit) rather than a constant whose message called it "the browser limit".
• A latent bug fixed in passing: the six style-buffer uploads were gated on updateStyles while the reorder branch rewrites all of them, so a positions-only populate left the GPU holding the previous permutation. Masked today only because an unchanged depth vector re-sorts identically.

Verification

A getParameter stub alone proves nothing — it changes what the app believes while the real driver still accepts the allocation — and the reported failure is silent, so a console-error assertion passes on broken code too. The Playwright layer therefore simulates the driver's refusal as well, and asserts the renderer never issues an allocation the device would refuse.

Verified red on the parent commit: renderer issued texture allocations the device refuses: [[2048,31]], and no warning surfaced. Green after.

• pnpm test — 2,270 unit tests green (all 7 pre-existing capacity-planner cases unchanged, as a regression guard)
• pnpm test:e2e — 121 passed, no regressions
• pnpm precommit + pnpm format:check green
• The reduced-stride path at 573,649 proteins — the exact case the issue reported — is in the opt-in load-large-bundle spec; the demo dataset's atlas is 2048×31, so the default suite can only reach the no-atlas path

Ordering

This must land before #456. Raising MAX_POINTS_DIRECT_RENDER to 2,000,000 on today's code makes the atlas 7813 rows — fatal on every 4096 device, a tier that works today — and a 1.5M→2M sequence on an 8192 device plans capacity 2,250,240 → height 8790, failing on mainstream hardware. #456 first would convert a minority-device bug into a mainstream one.

After both, the maximum drawable point count at full 8-slice fidelity becomes 2,097,152 on a 4096 device and 8,388,608 on an 8192 device; above ~4M the binding constraint is GPU memory, not texture size.

Not in this PR

Deferring allocation entirely for single-label annotations — the 42% GPU-residency win — is a follow-up. It only adds a second reason to enter the "no atlas" state this PR builds and tests on the error path, so it is small and cannot regress to corruption.

Please merge or rebase, not squash (repo-wide allow_squash_merge: false).

🤖 Generated with Claude Code

https://claude.ai/code/session_01USFuj7M2Ls1hpJXKaX2uJp