CI & dependency housekeeping (flaky installs, deprecated actions, no lockfile)

## Background

The `Tests` workflow on `main` intermittently fails at the **Install mighty** step due to transient PyPI download errors — e.g. [run 28341762815](https://github.com/automl/Mighty/actions/runs/28341762815) failed while downloading `pufferlib==2.0.6` (`stream error received: unspecific protocol error detected`) and passed on a plain re-run. The tests themselves never ran. This is a CI/dependency robustness problem,.

These overlap with the dependency-sweep feedback from the JOSS review (#122, #123 context).

## Items

- [ ] **No dependency lockfile.** CI warns: `No file matched to [**/uv.lock,**/requirements*.txt]. The cache will never get invalidated.` Without a lockfile the uv cache never persists deps, so every run re-downloads from PyPI — which is why a single flaky download fails the whole job. Adding a committed `uv.lock` would make installs cached, reproducible, and flake-resistant.
- [ ] **Flaky `pufferlib` install.** `pufferlib==2.0.6` bundles large binary assets (e.g. `resources/nmmo3/merged_sheet.png`) whose download intermittently truncates. Consider install retries and/or making `pufferlib` an optional CI path so a transient pufferlib download can't fail the core test job.
- [ ] **Deprecated GitHub Actions (Node 20).** `actions/checkout@v4`, `actions/setup-python@v5`, and `astral-sh/setup-uv@v5` are being force-run on Node 24; bump to current major versions.
- [ ] **Deprecated `set-output` command** used in the workflow — migrate to `$GITHUB_OUTPUT` environment files.

Start with the Tests workflow on main, especially the Install mighty step, and inspect its dependency and action configuration. Check how uv caching, pufferlib installation, action versions, and set-output are handled; done means a committed uv.lock, resilient installs, current actions, migrated output handling, and passing tests.

Written by the indexing model from the issue text.