idna==3.7 exact pin blocks consumers from picking up CVE-2026-45409 fix

[vmiller987]

roboflow currently pins idna==3.7 (an exact-version pin) in
setup.py / pyproject.toml. This was set by #249 in June 2024.

idna 3.7 has a known vulnerability: CVE-2026-45409, a denial-of-service
via crafted oversized unicode input to idna.encode(). The fix landed
in idna 3.15.

Because roboflow uses an exact pin rather than a range, downstream
consumers cannot upgrade idna without forking or using resolver
overrides. Tools like pip-audit flag this CVE in any project that
transitively depends on roboflow, with no clean remediation path.

idna's API is extremely stable across minor versions, and roboflow
does not appear to depend on any 3.7-specific behavior. A range
constraint like idna>=3.7,<4 or simply idna (matching other
dependencies in your setup.py such as requests, certifi) would
let consumers receive security patches without breaking roboflow.

Reproduction (any project depending on roboflow):

pip-audit
# → idna 3.7  CVE-2026-45409  Fix versions: 3.15

Suggested change in requirements.txt: replace idna==3.7 with idna
(or idna>=3.7,<4 for a tighter range).

Happy to open a PR if helpful. Let me know.