Fix CI

[crimsonknave]

CI is pulling 3.14 now and it's causing CI to fail. Based on the investigation in #99 it appears that a combination of dropping 3.9 support (as it's EoL) and removing mutmut solves the issues (it was the only reason we were including libcst, which was having the issue, also, there is a new version of libcst that supports python 3.14 that we could have updated to if we needed mutmut). mutmut hasn't been an active part of the dev cycle for a while as I had started to have issues with it in CI, but I'd intended to get back to it. Since I haven't yet we can remove it and add it back if time allows for it.

[Copilot]

Pull Request Overview

This PR pins the Python version used in the Pyright type checking workflow from the latest 3.x to a specific version 3.12.

• Changed the Python version specification from '3.x' to '3.12' in the pyright.yaml workflow

---

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

[Copilot]

[nitpick] The pytest workflow uses a matrix strategy to test against Python versions 3.9, 3.10, 3.11, 3.12, and 3.13, while the project supports Python >=3.6 (per pyproject.toml). Pinning pyright to only Python 3.12 means type checking won't catch type issues specific to other supported versions. Consider testing type checking against the minimum supported version (3.6 or 3.9) to ensure backward compatibility, or against multiple versions if version-specific type behaviors are a concern.

See below for a potential fix:

    strategy:
      matrix:
        python-version: [3.6, 3.9, 3.10, 3.11, 3.12, 3.13]
    steps:
    - uses: actions/checkout@v5
    - name: Set up Python
      uses: actions/setup-python@v6
      with:
        python-version: ${{ matrix.python-version }}

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
annotated_logger
__init__.py
Project Total

This report was generated by python-coverage-comment-action

[crimsonknave]

The publish to pypi job is failing because there is another PR that's already pushed the 1.3.2 version. I don't think it's worth bumping the version again just to make that job pass.