Retire Teak from the CI matrix, add Verawood, and raise the Django floor to 5.2

[blarghmatey]

Description/Context

Retire release/teak as a CI target and move the supported set to Ulmo, Verawood, and master. Verawood is not currently in the matrix, so this is a swap plus an addition, not just a removal.

Today's matrix in .github/workflows/ci.yml is master, release/teak, release/ulmo. release/verawood exists upstream and Tutor v22 targets it, so nothing blocks adding it.

Here is what each target actually pins, read from the upstream branches:

edx-platform branch	Django	Python	Tutor
release/teak (retiring)	4.2.20	3.11	v20.x
release/ulmo	5.2.11	3.11	v21.x
release/verawood (adding)	5.2.13	3.12	v22.x
master	5.2.16	3.12	git main

Sources: requirements/edx/base.txt and tox.ini on each branch; the Tutor mapping is from the Tutor CHANGELOG ("Upgrade to Verawood" ships in v22.0.0, "Upgrade to Ulmo" in v21.0.0, "Upgrade to Teak" in v20.0.0).

What this means for our declared version floors

Django: 4.x drops out entirely and the floor should rise to 5.2.

Teak is the only remaining target on Django 4.2. Once it's gone, every supported target runs Django 5.2, so the current floors are claiming support we no longer test:

• "Django>=4.0" — 24 files (23 plugins plus the root pyproject.toml)
• "Django>=4.2" — src/ol_openedx_sentry/pyproject.toml
• "django>=3.2" — src/ol_openedx_chat_xblock/pyproject.toml (already well below anything we test)

All of these should become Django>=5.2.

Python: nothing can be dropped, and that's worth stating explicitly.

The original framing of this work assumed retiring Teak would also let us drop a Python version. It doesn't. Ulmo runs on Python 3.11, the same as Teak, so requires-python = ">=3.11" (26 files) has to stay until Ulmo itself is retired. Same for ruff target-version = "py311" and mypy python_version=3.11 — both should stay pinned to the lowest supported version.

The Python change that is needed runs the other way: Verawood and master are on 3.12, and the CI matrix only lists python_version: [3.11]. See the open question below.

Plan/Design

1. ci.yml — drop release/teak, add release/verawood.
2. .github/actions/setup-tutor/action.yml — this is the branch → Tutor mapping introduced in ci: add caching to speed up tutor-based CI workflow #802 (merge that first, or fold this into it). The current logic special-cases Teak → v20 and Ulmo → v21, with Ulmo as the catch-all else. Verawood must get an explicit >=22.0.0,<23.0.0 case, otherwise it silently falls through to the Ulmo branch and installs Tutor 21 against a Verawood platform:

   if [[ "$EDX_BRANCH" == "release/ulmo" ]]; then
     pip install "tutor>=21.0.0,<22.0.0"
   elif [[ "$EDX_BRANCH" == "release/verawood" ]]; then
     pip install "tutor>=22.0.0,<23.0.0"
   elif [[ "$EDX_BRANCH" == "master" ]]; then
     ...

   Removing the Teak case also lets the else fallback go away in favour of explicit branches — a wrong-Tutor-version install produces confusing downstream failures rather than a clean error.
3. .github/workflows/ci-image-cache.yml — same matrix change; it must stay in sync with ci.yml (also from ci: add caching to speed up tutor-based CI workflow #802).
4. Raise the Django floor to >=5.2 across the 26 pyproject.toml files listed above.
5. Version bumps — per AGENTS.md, any plugin whose pyproject.toml changes needs a version bump before merge to main, since publishing to PyPI is automatic. Raising a dependency floor is a compatibility change, so this touches essentially every package. Worth deciding up front whether that's one bulk minor bump across the board.
6. Docs — docs/README.rst and the per-plugin README.rst files reference Tutor versions and supported releases; sweep for Teak mentions.

Open questions

• Is the python_version matrix dimension meaningful? Tests execute inside the Tutor container against the container's Python, not the runner's — the runner's Python only serves uv build and the Tutor CLI. So python_version: [3.11] may not be testing what it appears to test. Either it should track each branch's real Python (3.11 for Ulmo, 3.12 for Verawood/master, which means pairing it with edx_branch rather than crossing it) or it should be dropped as vestigial. Worth resolving rather than leaving a dimension that reads as coverage it isn't providing.
• Timing against Teak's upstream support window. If anyone is still running Teak in production, dropping CI coverage means plugin releases stop being verified against it even though the Django floor will formally exclude it. Confirm no deployment still needs it before merging.
• Do we hold this until ci: add caching to speed up tutor-based CI workflow #802 lands? ci: add caching to speed up tutor-based CI workflow #802 rewrites the Tutor setup into a shared composite action and adds a second workflow with its own copy of the matrix. Doing this first means redoing it there; doing it after is a small, contained edit.