feat(bundle): parquetbundle v3, 2x faster 1/3 memory usage

[peymanvahidi]

Summary

Loading a large dataset is about twice as fast and uses about a third of the memory.

User side changes

Noting dramatically. They use the same pipeline and python package as before, the way that we save the parquetbundle and later process it in UI is different, which is the reason of these improvements.

Numbers below are the tests on the old and new parquetbundle dataset of SwissProt (around 570k data points):

	Old	New
File chosen to usable plot	13.3 s	7.6 s
Peak tab memory	~2.5 GB	~0.8 GB
Memory held after loading	460 MB	221 MB
File size on disk	44.9 MB	36.4 MB
Longest frozen moment	4.5 s	4.5 s
Hover, pan, zoom after load	unchanged	unchanged
Switch to a multi-valued annotation	2.2 s	3.0 s

Nothing about the visualisation changed. A screenshot comparison of the fully loaded app found the images identical.

What changed in the .parquetbundle format

Piece	Before	Now
Categorical value	string per row	int32 code plus a label dictionary
Multi-value cell	one string, delimiter-joined	per-row hit count, codes in a side buffer
Score / evidence code	appended into the same string	float64 and int32 buffers, per-hit counts
Projection coordinates	long table, identifier repeated per row	wide float column pair per projection
Column meaning	inferred by scanning values at load	declared in a manifest in the file

Compatibility

Existing files still work. Every dataset already published loads exactly as before, so nothing needs regenerating and this can ship without coordination.

Open questions

1. I think we could drop support for the old format at some point, and I would like opinions rather than agreement.
2. I implemented these changes via Claude and by providing it the embedding atlas repo, this is why it was more interested in making these changes instead of using DuckDB:

**Why not DuckDB**
We looked at it closely, since Apple's Embedding Atlas ships it and handles millions of points. Three things settled it.

It is not what makes them fast. Their point data does not come from SQL at render time: one query runs, the results are
copied into typed arrays, and the GPU draws those. Their scale comes from the renderer, not the database.

It does not fix our bottleneck. Our slow step was parsing packed annotation strings, and a query engine parses the same
strings. At this size a plain loop over an integer column filters in about a millisecond, while a round trip to an in-browser
database costs more than that before any work starts.

It costs real money. Around 5 MB of extra download, a second full copy of the dataset in memory, and a single-threaded
engine with known trouble above a couple of million rows. We were trying to reduce memory, not double it.

Where it would genuinely help is ad-hoc analytics over arbitrary columns: cross-filtered side charts, sortable paged tables,
joins across extra tables. If we want those later, it can be loaded on demand behind that panel and kept off the load and
render paths entirely.

[peymanvahidi]

What I'd do next is to check if we can implement the density plots to the current implementation that we have.

[peymanvahidi]

I'll not fix the CI errors yet, I'll do if after we decided about the backward compatibility.
@tsenoner could you tell me what you think about the backward compatibility? are you ok if we remove it?