validate-task.yml's lint job pins Python 3.13, narrowing the type check and blocking a uv.lock repo above that floor #1485

Split out of #1475, which settled the unit-test job's interpreter and said explicitly that "whether the lint job needs the same treatment is a separate call". #1484 took the first half and left this one filed rather than widened into it.

The finding

validate-task.yml's lint job pins its interpreter and exposes no input to change it. Read on the branch #1484 merges:

.github/workflows/validate-task.yml:202    python-version: "3.13"

The python-versions input #1484 adds reaches the unit-test job's matrix alone. Nothing a caller can pass moves the lint job.

Two separate costs, and only one is settleable downstream

A type-check target, which a repository can settle in its own configuration. The Type check Python step runs mypy or pyright under that pinned interpreter. Each defaults its target to the interpreter it runs under, so a repository declaring requires-python = ">=3.13" and testing 3.13 and 3.14 gets its type check performed at 3.13 alone. A 3.14-only typing error, a sys.version_info branch or a typeshed symbol version-gated on one, passes the hub gate with nothing failing and nothing warning. That is the same silent-narrowing shape #1475 was filed for, moved from the test leg to the type checker.

A repository closes this itself by naming a version in its own [tool.mypy] or [tool.pyright] section, and #1484's adopter docs say so. ruff needs nothing, taking its target from requires-python where a [project] table declares one. So this half is a documented workaround rather than a block.

A lockfile floor, which it cannot settle anywhere. The Sync Python dependencies step runs uv sync --all-groups --frozen under the same pinned interpreter, guarded on a committed uv.lock. A repository carrying a uv.lock whose requires-python floor is above the pin fails that step outright: UV_PYTHON resolves to 3.13, which cannot satisfy the lockfile's own requirement. No [tool.*] section reaches it and no value of python-versions reaches it. That repository cannot adopt the gate at all.

No current adopter is in that state. aiopurpleair declares >=3.13 and is unaffected, and a repository whose Python dependencies come from requirements*.txt skips the step entirely, its guard naming uv.lock. It is a constraint on the next adopter rather than a live break, which is why it is filed rather than fixed under #1484.

Suggested remedy, and what makes it not obvious

The shape #1484 used does not transfer unchanged. Its matrix is over interpreters that each run the same tests, where linting the same sources under two interpreters is mostly redundant work: ruff reports identically, and only the type check and the sync actually differ. So a lint-python-version scalar input, defaulting to today's pin, is likely the right size rather than a second matrix, and it would settle both costs at once. A matrix here would double every lint leg, the doc gates included, to re-derive findings the first leg already produced.

Whether the doc-lint block should move out of a job that gains an interpreter dimension is the question to answer first, since it is language-independent and pays for any fan-out it sits inside.

Not filed here

No registry or spec change. No audit report is being written back, and #1484's adopter docs already state both costs so a reader is not misled while this is open.