Migrate `load_and_normalize` onto the streaming executor

[fishidaho]

load_and_normalize (src/vsparse/_rapid_load.py) is the one entry point real callers actually use today, and it's the one place the current
fully-materializing behavior is directly user-visible. Building a streaming executor (#39 ) doesn't help anyone until this function, or a
clearly-documented streaming replacement for it ,actually uses it.

Proposed scope

• Reimplement load_and_normalize's filter/normalize pipeline on top of Implement a streaming executor with prefetch and a memory budget #39 's streaming executor, preserving its existing numerical contract
  (validated to 0.0 absolute error against recomputation).
• Decide on the migration story. In other words, does load_and_normalize change behavior in place (same signature, now streaming under the hood, with a memory-budget kwarg), or does it stay as the "decode everything" fast path for callers who know their data fits, with a new streaming-first entry point alongside it?

Acceptance criteria

• The full parafac2-style pipeline (filter, normalize, feed to a matmul-consuming caller) runs under a defined memory ceiling on a dataset large enough that the current implementation would not.
• Existing tests/test_rapid_load.py behavioral guarantees still hold.
• README/docs are updated to point at whichever function is now the recommended atlas-scale entry point.

References

• src/vsparse/_rapid_load.py, README.md (load_and_normalize section).

[aarmey]

I actually thought we would get rid of load_and_normalize(), opting for the more general load, then subset, then normalize workflow. Part of the purpose of having a normalization wrapper was to easily allow for other forms of normalization/transformation. Separating the individual steps allows one to mix and match functionality as needed, rather than writing one loader with too many options.

[fishidaho]

@aarmey Thats what I was thinking as well. One proposition I have played around with in a scratchpad is to have normalization be a declarative recipe where we factorize the dataset into a set of statistical functions. After a few iterations, it looks like the appropriate way to do this would be to set:

y[i,j] = ( g( x[i,j] * a[i] * b[j] ) - c[j] ) * s[j]

Operation	Type	Description	Role
a	float64[n_cells]	per-cell scale	depth normalization
b	float64[n_genes]	per-gene scale	gene scaling inside the transform
g	scalar function	monotone, g(0) = 0	log1p / log10(1+1000x) / identity
c	float64[n_genes]	per-gene center	mean-centering
s	float64[n_genes]	per-gene post-scale	variance scaling

Then, the user would just need to supply coefficients and/or actual functions for each operation which can yield common normalization schemes such as:

Recipe	a[i]	b[j]	g	c[j]	s[j]
Raw counts	1	1	id	0	1
CP10K + log1p	1e4/depth	1	log1p	0	1
parafac2 prepare_dataset	med/depth	1/gsum	log10(1+1000x)	mean	1
Scanpy scale()	1e4/depth	1	log1p	mean	1/sd
Pearson-residual-like	1/depth	1/gsum	sqrt	mean	1/sd

This kind of format would also directly enable us to do lazy normalization as suggested in the streaming executor #39. This is mainly due to three identified properties:

1. Separability. a depends only on the cell index and b, c, s only on the gene index. The complete state of a normalization is O(n_cells + n_genes) floats so never O(nnz) and never O(n×m).
2. Entrywise independence. y[i,j] depends on x[i,j] and nothing else, so the transform fuses into any kernel already visiting a nonzero. This means we have no extra pass, no coordination, and most importantly that it streams.
3. Rank-1 dense part. Because g(0) = 0, every structural zero maps to exactly -c[j]*s[j]. So Y = Δ + 1 ⊗ (-c*s) with Δ zero off the stored nonzeros.

[aarmey]

Very cool!