test: register slow pytest marker and apply to training tests

[sadamov]

Describe your changes

Register a slow pytest marker in pyproject.toml and apply @pytest.mark.slow to test_training (parametrised over all datastores) and test_training_output_std because they run a real trainer.fit loop and take minutes per parametrisation.

This relies on pytest's built-in marker filtering rather than introducing a custom flag:

• pytest (no flags) runs the full suite, slow tests included. CI uses this and continues to exercise everything.
• pytest -m "not slow" skips slow tests, for fast local iteration during contributor development.
• pytest -m slow runs only slow tests, e.g. when debugging a training regression.

Motivation: I needed this in #635 for the ERA5 boundary integration test, then realised the mechanism is independently useful for the existing trainer.fit-based tests too. Landing the marker separately so #635 doesn't have to ship two things at once, and so #231's test_state_only_datastore_training_setup_runs (and any future trainer.fit-based regression) can opt in via the same marker.

Coordination with #615 (@jishanahmed-shaikh): orthogonal. The slow marker is about execution time, the unit/integration split is about scope. They coexist: an integration test can be fast (DummyDatastore) and a unit test can be slow (large numerical fixture).

Earlier iteration of this PR introduced a custom --run-slow CLI flag with skip-by-default behaviour. @observingClouds suggested the inverse (run-by-default with --skip-slow), and the cleanest resolution was to drop the custom flag entirely and rely on pytest's native -m selection. Pytest already supports exactly this pattern with zero custom code.

No new dependencies. No CI changes.

Verified locally:

• pytest tests/test_training.py --collect-only -q -> all 6 tests collected
• pytest tests/test_training.py -m "not slow" --collect-only -q -> 2 collected, 4 deselected

Issue Link

Refs #635, refs #599

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.

Checklist for reviewers

Each PR comes with its own improvements and flaws. The reviewer should check the following:

• the code is readable
• the code is well tested
• the code is documented (including return types and parameters)
• the code is easy to maintain

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

Checklist for assignee

• PR is up to date with the base branch
• the tests pass
• (if the PR is not just maintenance/bugfix) the PR is assigned to the next milestone. If it is not, propose it for a future milestone.
• author has added an entry to the changelog (and designated the change as added, changed, fixed or maintenance)
• Once the PR is ready to be merged, squash commits and merge the PR.

[observingClouds]

This is a great idea @sadamov. I wonder if it is better to define the inverse of this, e.g. a --skip-slow flag that needs to be set. So by default the whole suite is run and only in the case when you are familiar with the testing, you add the --skip-slow flag to skip some tests.

[sadamov]

@observingClouds, I am glad you mentioned this. I just learned that there is a built-in -m marker selection in pytest 35329d9. Default pytest now runs the full suite (slow tests included), and contributors can opt out with pytest -m "not slow" during local iteration. CI is also back to plain pytest with no flag.
This should be exactly what you requested and the built-in reduced the number of lines to 9 :D

[observingClouds]

Just a few more small suggestions.