build: refresh vulnerable dependencies while retaining Python 3.9

[krowvin]

Refresh locked idna, urllib3, setuptools, filelock, and virtualenv versions while retaining Python 3.9 support. Python-specific constraints keep urllib3 2.6.3 and setuptools 82.0.1 on Python 3.9 and select patched urllib3 2.7.0 and setuptools 84.0.0 on Python 3.10+. This extends the existing split for requests, Black, pytest, and filelock. The urllib3 requirements are also included in the built wheel's metadata for downstream pip installs; setuptools remains a development dependency.

Comparing the updated lockfile with GitHub's advisory ranges removes eight of the fifteen open dependency alerts: #7, #9, #11, #12, #13, #15, #16, and #22. Seven remain (#14, #17, #19, #20, #21, #23, #24) because the lockfile retains affected versions for Python 3.9. For the packages covered by these alerts, Python 3.10+ now selects patched releases. This does not resolve the Python 3.9 vulnerabilities or claim that all dependencies are vulnerability-free. GitHub will reassess default-branch alerts after merge.

Add Python 3.10 to the unit-test matrix alongside 3.9 and latest Python to cover both sides of the dependency split.

Validation: Poetry lock consistency, a fresh Python 3.13 install, all 98 mock/doctest tests, strict mypy over 38 source files, the YAML pre-commit check, and wheel build pass locally. The built wheel contains the expected Python-specific urllib3 requirements. All nine PR checks pass on commit 9d59f4c, including dependency installation, tests, and strict type checks on Python 3.9, 3.10, and latest Python, plus code checks, CodeQL, and SonarCloud.

[msweier]

Is it worth pinning Python 3.9 to the older dependencies and letting the newer versions of python upgrade? Or does that add to much complexity.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud