Design a `.raw` / layer integration path for VCSCAnnData

[fishidaho]

VCSCAnnData.raw_X (src/vsparse/_anndata_class.py) is a bolted-on plain attribute and explicitly not wired into anndata's own .raw/Raw machinery, per the class docstring, because that machinery has the same type-validation restriction that required VCSCAnnData to override X in the first place. The same is true of layers. This is a real, working escape hatch today, but it means .raw and layers don't behave like anndata users expect.

Proposed scope

• Does .raw stay a separate, non-standard attribute indefinitely, or is there a path to making it interoperate with anndata's real .raw for callers that need it (e.g. by exposing a decompressed view lazily on access)?
• Same question for layers holding VCS-typed arrays vs. plain scipy ones.
• How this interacts with Design a composable lazy Selection object for VCSCAnnData #25 's Selection object. Does a lazy selection need to carry .raw/layer filters through composition the same way it does for X?

References

• src/vsparse/_anndata_class.py class docstring.

[aarmey]

Yeah... not sure what the right approach here is. Given the structure of VCS arrays, they will essentially always only contain the raw counts, not normalized data. I suppose .X could contain a stub to point to .raw, or .X could also be subsetted to only certain genes or cells. Also, .X or .layers might contain normalized views of the data. However, I think the goal would be to not duplicate the data at these other arrays. Maybe some kind of pointer-based approach would work best; then if someone has to have an array of a non-VCS type, it would work without modifications.

Maybe the actual VCS array should always be at .raw, and everywhere else should only contain views?