chore(deps): migrate dependency management to pyproject.toml + uv (v2)

[matrixise]

Summary

Reworked take on #172, from scratch, rebased on current master (that PR is now CONFLICTING/stale and had a real CI regression, see below). Replaces the requirements/*.in + pip-compile-generated requirements/*.txt workflow with a single pyproject.toml + committed uv.lock, matching the project's move to a uv-only workflow.

• pyproject.toml: [project.dependencies] (main) + a dev dependency-group, tool.uv.package = false (this is a deployable Django app, not a distributed library). Drops the now-unused pythonie/setup.py
• uv.lock: committed, resolved lock file (115 packages)
• All current dependency versions carried over unchanged, including yesterday's security patches (django, wagtail, pillow, sqlparse, soupsieve, djangorestframework, msgpack, pip). django capped at <6.1 and ruff pinned to 0.15.16 to avoid incidental version bumps changing behavior as a side effect of this migration
• No more root requirements.txt: Heroku's Python buildpack now installs from uv.lock natively (see "Heroku deployment" below)
• Dockerfile: uv sync --frozen --all-groups, .venv on PATH so existing docker compose run ... python ... invocations are unchanged
• Taskfile.yaml / toast.yml: dependencies:* tasks now call uv lock / uv lock --upgrade[-package] / uv tree / uv run pip-audit instead of uv pip compile
• .github/workflows/test.yml: astral-sh/setup-uv + uv sync --all-groups, every step prefixed with uv run. Keeps every existing quality gate (ruff format, ruff check, pip-audit, Django tests). This is the part Migrate dependency management to pyproject.toml with uv #172 regressed, silently dropping format/lint/security checks and downgrading actions/checkout/setup-python to @v2
• .tool-versions (asdf) → mise.toml (native format for the team's tool version manager going forward)
• Docs (README.md, CONTRIBUTING.md, DEVELOPMENT.md, CLAUDE.md) updated to the uv sync / uv run workflow

Heroku deployment

The heroku/python buildpack picks its package manager from the files at the repo root, and aborts the build (Error: Multiple Python package manager files were found) if it finds more than one of requirements.txt, poetry.lock, uv.lock. An earlier revision of this PR kept a uv export-generated requirements.txt next to uv.lock, which would have broken the deploy. It has been removed, along with the dependencies:export task.

With only uv.lock present, the buildpack (uv support since v286, 2025-05-13):

• reads the Python version from .python-version (3.13, already on master; runtime.txt is deprecated and not needed)
• runs uv sync --locked --no-default-groups into the slug's system Python, so the dev group is not installed and uv.lock must be in sync with pyproject.toml
• runs collectstatic as before

At runtime python and gunicorn live in /app/.heroku/python/bin and uv is not needed, so the Procfile (release: python pythonie/manage.py migrate ..., web: gunicorn ...) is unchanged.

The pythonie app uses heroku/python from the buildpack registry (not pinned to a tag), so it gets the current buildpack.

Why not just update #172?

#172 is 9 months stale, conflicts with master (mostly from yesterday's dependency-security PRs touching requirements/*.txt), pins Django 5.2.x/Wagtail 7.2.x (both outdated now), and its CI workflow drops ruff format --check, ruff check and pip_audit entirely while downgrading actions/checkout/setup-python to @v2. Rather than untangling that history, this PR rebuilds the same end state cleanly on top of current master. Happy to close #172 once this is reviewed, or keep both open for comparison, your call.

Test plan

• uv sync --all-groups installs cleanly (115 packages resolved)
• uv lock --check: lock file in sync with pyproject.toml
• uv run python pythonie/manage.py test pythonie --settings=pythonie.settings.tests (SQLite, 7/7 passed)
• uv run ruff format --check pythonie / uv run ruff check pythonie: both clean, matching master
• uv run pip-audit: no known vulnerabilities
• docker build . succeeds; python, ruff, django/wagtail imports resolve via the .venv on PATH inside the image
• Real heroku-buildpack-python (v352) bin/compile run against this branch in the heroku/heroku:24-build image, with production config vars: Python 3.13.15 from .python-version, uv sync --locked --no-default-groups (68 packages), collectstatic OK (257 files)
• Runtime simulation with the slug at /app and a clean env: manage.py check --settings=pythonie.settings.production reports no issues, the migrate command loads, gunicorn pythonie.wsgi boots and serves requests (HTTP 301 SSL redirect, as expected)
• heroku buildpacks -a pythonie: heroku/python from the registry, not pinned
• First real deploy: watch the build log and heroku releases, keep task heroku:rollback at hand (the first uv build is a full rebuild since the pip cache is discarded)

[matrixise]

An independent review found a real blocker: heroku-buildpack-python fails the build when it finds more than one package-manager file at the repo root (requirements.txt and uv.lock). This is no longer just a deprecation warning. I had committed a uv export-generated requirements.txt for Heroku, which would have broken the deploy.

Fix pushed (7d67c67): removed requirements.txt and the dependencies:export task. The buildpack handles uv.lock natively (uv sync --locked --no-default-groups into the slug's Python). .python-version (already present, 3.13) still drives the buildpack's Python version.

Verified:

• locally with uv sync --locked --no-default-groups + manage.py check --settings=pythonie.settings.production
• by running the actual buildpack (v352) against this branch in the heroku/heroku:24-build image: build, collectstatic, then manage.py check, migrate loading and gunicorn boot with the slug at /app
• heroku buildpacks -a pythonie shows the unpinned registry heroku/python buildpack, which has supported uv since v286