Compute standardization stats in float64

[RudraDudhat2509]

Describe your changes

The standardization std was sqrt(E[x²] - E[x]²) from float32 moments, which cancels when the mean is large compared to the std (mean 1e5, std 100 gave 90.5, std 5 gave NaN, a constant field gave 45 instead of 0). Details, the simulation and how NumPy, scikit-learn, PyTorch, anemoi-datasets and mllam-data-prep handle it are in #758.

• sample_moments: per-sample mean and mean of squares in float64, one sample at a time so memory stays at one sample. Used for the parameter and diff passes, flux stats use float64 too.
• _std_from_moments: clamps rounding-level negative variance to 0 and raises on clearly negative variance, instead of a NaN.
• Stats are still saved as float32, since the diff pass applies them to float32 batches.

Measured on a MEPS-sized batch (4 x 65 x 63784 x 17, CPU): 1.05 s to 1.20 s per batch, lower peak memory for large batches.

10 new tests, 5 of them fail on the old computation (std 100, 20 and 5, a constant field, and inconsistent moments). main() itself isn't covered since it needs MEPS data. The two lines in main overlap with #748.

No new dependencies required.

Issue Link

closes #758

Type of change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📖 Documentation (Addition or improvements to documentation)

Checklist before requesting a review

• My branch is up-to-date with the target branch - if not update your fork with the changes from the target branch (use pull with --rebase option if possible).
• I have performed a self-review of my code
• For any new/modified functions/classes I have added docstrings that clearly describe its purpose, expected inputs and returned values
• I have placed in-line comments to clarify the intent of any hard-to-understand passages of my code
• I have updated the README to cover introduced code changes
• I have added tests that prove my fix is effective or that my feature works
• I have given the PR a name that clearly describes the change, written in imperative form (context).
• I have requested a reviewer and an assignee (assignee is responsible for merging). This applies only if you have write access to the repo, otherwise feel free to tag a maintainer to add a reviewer and assignee.

Author checklist after completed review

• I have added a line to the CHANGELOG describing this change, in a section
  reflecting type of change (add section where missing):
  • added: when you have added new functionality
  • changed: when default behaviour of the code has been changed
  • fixes: when your contribution fixes a bug
  • maintenance: when your contribution is relates to repo maintenance, e.g. CI/CD or documentation