Epic: Data layer — CSR sparse support, slices vs Vec in Array traits, parquet IO

[Mec-iS]

Tracking issue for data-layer work. Highest blast radius of all epics: the Array/Array1/Array2 traits are foundational. Do not start code before an RFC is agreed here.

Member issues

• Array conventions: support CSR #156 — CSR (sparse) matrix support
• Consider the possibility to use [T] instead of Vec<T> in trait Array #199 — use [T] instead of Vec<T> in trait Array
• Allow read/write of parquet files #249 — parquet read/write

Why grouped

#156 and #199 both reshape the core array abstractions every algorithm builds on; #249 adds an IO surface whose dependency weight and wasm story need a joint call with the data-model work. Sequencing them together prevents repeated breaking changes to the same traits.

Constraints (repo conventions)

• Keep the bespoke numeric/linalg system and its performance intact — known-answer tests must pass unchanged.
• Zero-copy access via iterator(...) / view traits is mandatory for any new storage layout.
• Dataset serialization helpers must not trigger file writes on wasm targets.
• New dependencies need a size/feature-gate justification (parquet is heavy — expect a dedicated optional feature).

RFC requirements

Post a short RFC comment covering: trait-level changes and their breaking-change scope, CSR coverage plan (which algorithms first), parquet feature gating, no_std impact (v0.7 roadmap).

Acceptance criteria

• RFC agreed by a maintainer
• Members implemented or explicitly descoped
• CHANGELOG updated; breaking changes flagged in it