requires-python (>=3.9) contradicts stated support (classifiers ≤ 3.13) — installs are attempted on Python 3.14 and fail

[kgartland-rstudio]

Prework

• Read and agree to the code of conduct and contributing guidelines.
• If there is already a relevant issue, whether open or closed, comment on the existing thread instead of posting a new issue.

Description

multimark's metadata is internally inconsistent about Python 3.14:

• Classifiers declare support only through 3.13 — 3.14 is not listed.
• requires-python = ">=3.9" has no upper bound, so it permits 3.14.

Resolvers (pip/uv) honor requires-python and ignore classifiers. So despite 3.14 not being a declared/supported version, resolvers will still select multimark on 3.14, find no cp314 wheel, fall back to building the cmark-gfm C extension from sdist, and fail in any environment without a C toolchain:

building 'multimark._binding' extension
error: command 'gcc' failed: No such file or directory
ERROR: Failed building wheel for multimark

Reproducible example

docker run --rm python:3.14-slim pip install "multimark==0.2.0" # FAILS (no cp314 wheel, no compiler)
docker run --rm python:3.13-slim pip install "multimark==0.2.0" # succeeds (cp313 wheel)

Expected result

We would expect that 3.14 can't be selected.

Development environment

• Operating System: [Found in CI on posit-ubuntu-24-amd64-2-core]
• multimark Version: [e.g., 0.2.0]

Add any other context about the problem here.

Hits downstreams transitively: great-tables>=0.22.0 added a multimark>=0.1.3 dependency, pulled in via querychat. Any Python 3.14 environment without a compiler fails to install, and downstreams can't guard against it because the enforced contract says 3.14 is allowed.