Mark Python 3.14 support and drop Python 3.9

[jiasli]

Mark Python 3.14 support and drop Python 3.9, following the same pattern as:

• Mark Python 3.12 support #279
• Mark Python 3.13 support #290

---

🤖 This PR is assisted by VS Code GitHub Copilot, with Claude Opus 4.6 Medium model, and human-verified.

Prompt:

Follow the same pattern of #279 and #290 to add Python 3.14 support and meanwhile remove Python 3.9 support.

[Copilot]

Pull request overview

Updates the project’s declared and CI-tested Python version support by adding Python 3.14 and removing Python 3.9, aligning with the prior support-bump PR patterns referenced in the description.

Changes:

• Update tox environments to drop py39 and add py314.
• Update package classifiers to drop Python 3.9 and add Python 3.14.
• Update Azure Pipelines matrix to remove Python 3.9 runs and add Python 3.14 runs; update wheel build job to use Python 3.14.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
tox.ini	Adjusts envlist to stop testing on 3.9 and start testing on 3.14.
setup.py	Updates Trove classifiers to reflect 3.10–3.14 support (drops 3.9).
azure-pipeline.yml	Updates CI matrix and wheel build job to run with Python 3.14 instead of 3.9/3.13.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jiasli]

Quote the version number according to #296 (comment).

Unquoted 3.10 did appear before in #254, but it didn't cause any issue. Here is the explanation from Copilot:

---

You're right — that commit does show versionSpec: 3.10 unquoted. So the question is valid: why didn't that break?

The answer is that Azure Pipelines doesn't use a strict YAML 1.1 parser. Azure Pipelines uses a custom YAML parser that treats values like 3.10 as strings, not floats. So 3.10 is not silently truncated to 3.1.

This is different from standard YAML 1.1 (used by tools like PyYAML), where 3.10 would indeed be parsed as the float 3.1. But Azure Pipelines specifically handles version-like values as strings to avoid this exact pitfall.

So the Copilot review comment is technically correct in general YAML terms (quoting is best practice and safer), but practically incorrect — it wouldn't actually cause an issue in Azure Pipelines. The existing unquoted 3.10 worked fine for the same reason: Azure Pipelines doesn't apply float coercion to these values.

That said, quoting is still good hygiene for portability and clarity.