Replace mypy type-check gate with ty (astral-sh)

[sadamov]

Describe your changes

Targets mllam#673 (not main): replaces the mypy type-check gate that mllam#673 introduces with ty (astral-sh).

• Swap the mirrors-mypy pre-commit hook and [tool.mypy] config for ty. Unlike mypy with ignore_missing_imports, ty resolves imports against the project venv, so it type-checks against real torch/lightning/xarray types.
• Migrate the mypy # type: ignore[...] comments to explicit # ty: ignore[<rule>] (ty does not honour mypy's code-specific directives); a few lines are rewrapped where ty's longer rule names would exceed the 80-char limit.
• [tool.ty] downgrades the noisy possibly-missing-submodule rule and pins the environment to .venv.
• ty runs as a local pre-commit hook and in the install-and-test CI job after uv sync; it is skipped in the deps-less linting CI job (it needs the venv to resolve imports).
• mypy and the types-* stub dev deps are dropped from pyproject.toml and uv.lock.

No dependencies at runtime.

Two coordination points:

• Blocked on Fix graph LAM GNN kwarg handling mllam/neural-lam#688: ty currently reports 2 findings, both the train_model.py mesh_up/down_gnn_type bug that Fix graph LAM GNN kwarg handling mllam/neural-lam#688 fixes. CI hard-fails until Fix graph LAM GNN kwarg handling mllam/neural-lam#688 merges and this rebases. Draft until then.
• Annotation-coverage: ty has no disallow_untyped_defs equivalent, so it does not enforce that every function is annotated (the point of Enforce 100% type-hint coverage and align typing to PEP 585/604 mllam/neural-lam#673). That enforcement should move to ruff's flake8-annotations (ANN) rules in Modernize linting stack: migrate to Ruff and streamline pre-commit hooks mllam/neural-lam#614 (the codebase is already ANN-clean with --ignore ANN401). Until Modernize linting stack: migrate to Ruff and streamline pre-commit hooks mllam/neural-lam#614 lands with ANN, coverage is achieved but ungated.

Issue Link

refs mllam#670

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)

(Maintenance / CI-CD change - the Type-of-change list above has no maintenance option; see the CHANGELOG Maintenance entry.)

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.