FIX: Correct install metadata: requires-python, dependency floors, classifiers

[mmcky]

Problem

pyproject.toml contradicts itself and reality:

• requires-python = ">=3.7" — Python 3.7 has been EOL since June 2023, and 3.8–3.11 are neither in CI nor in the classifiers, which list exactly 3.12 / 3.13 / 3.14.
• Floors numpy>=1.17.0 (2019), numba>=0.49.0 (2020), scipy>=1.5.0 (2020) permit pip to build environments untested for years — while the code has moved on (util/compat.py exists for NumPy≥2 semantics; _dle.py carries a NumPy 2.4 workaround). The floors are also internally inconsistent with the classifiers: numba 0.49 cannot run on any Python version the classifiers name (the first numba supporting 3.12 is 0.59).

Net effect: pip install quantecon succeeds on configurations we do not support, and failure surfaces later as user bug reports. Wrong metadata is a shipped defect.

Proposed change

1. Set requires-python = ">=3.12" to match CI and classifiers (or extend CI first if broader support is intended — either way, make the three agree).
2. Raise floors to the oldest combination actually exercised, e.g. the versions resolved by environment.yml on the oldest supported Python.
3. While in the file: decide Development Status :: 4 - Beta (12+ years in; 5 - Production/Stable likely reflects reality) — one-line change, same edit.
4. Add a release-checklist line: metadata review on every Python-version or floor change.

Acceptance criteria

• requires-python, classifiers, and the CI matrix name the same version set
• pip install on a now-unsupported Python is refused by the resolver (users there keep resolving to older quantecon releases — the correct outcome)
• Floors verified by at least one CI leg or a documented local run

---

From the July 2026 technical-debt audit (AI-assisted; claims verified against 28d4b3b on 2026-07-25).

[oaksprout]

Would you want this one done? — Fix quantecon's pyproject.toml so its declared Python-version floor and dependency-version floors (numpy/numba/scipy) actually match what CI tests and what the trove classifiers claim — currently it advertises support far older than anything actually exercised or working. If yes, we'll do it and open a PR; if not, say so (or just ignore this) and we won't touch it.

How it works: an AI agent does the work against your write-up; it's independently checked in a clean container (your test suite, network off) before anything reaches you; a human reviews it, submits it, and answers the review. You keep full control — nothing lands unless you merge it.

Recent examples of the same flow on other projects: strawberry-graphql/strawberry#4555, sigstore/sigstore-python#1845, optiland/optiland#694.

We're testing whether work offered this way is useful to maintainers — a blunt "no" is as helpful as a yes.