Simplify the canonical data loading boundary

[jder]

Summary

• rebase the canonical-reader refactor needed by Add opt-in Rust OM4 data loader #800 onto the LLC support landed in Add LLC CPU data canonicalization #670
• replace the overlapping DatasetSpec / CanonicalDataset / OceanData abstractions with DataLayout, CanonicalSource, BatchPreprocessor, HostBatch, and ModelBatch
• make the storage-independent reader accept explicit time indices and canonical channel names
• push prognostic-versus-boundary selection into read requests instead of maintaining sliced source objects
• move OM4-specific canonicalization into Om4DataSourceConfig.canonicalize_datasets
• make OM4 and LLC canonicalizers derive their channel selections from variable keys and return the resulting DataLayout
• keep raw source conventions such as LLC staggered masks and OM4 mask names out of DataLayout
• preserve the grid-geometry, analysis-ready writer output, and training-progress changes currently on main

This intentionally does not add an LLC Rust loader. It establishes the narrower CanonicalReader seam that the Rust loader can implement later without exposing xarray or source-specific naming to the training pipeline.

Impact

Callers now request ordered canonical channels directly. Canonicalization owns source-specific naming, dimension, mask, and variable-selection rules, while DataLayout describes only the canonical/model-facing result. This removes repeated variable filtering and normalization wrappers from the hot data-loading path.

Validation

• uvx pre-commit run --all-files
• CUDA_VISIBLE_DEVICES='' uv run pytest -q -m 'not manual and not cuda'
  • 323 passed, 2 skipped, 10 xfailed