Fix CI mypy command on free-threaded Python

[EliahKagan]

When the version is represented as 3.13t, the --python-version option needs an operand of 3.13, not 3.13t.

(This, and the fix here, will automatically apply to later threaded Pythons, such as 3.14t, too.)

---

Before this change, in the Python 3.13t run:

+ mypy --python-version=3.13t usage: mypy [-h] [-v] [-V] [more options; see below] [-m MODULE] [-p PACKAGE] [-c PROGRAM_TEXT] [files ...] mypy: error: argument --python-version: Invalid python version '3.13t' (expected format: 'x.y') 

This isn't new--it's always happened in the mypy step in the 3.13t job. We just never noticed it, because the mypy step always reports failure even when working correctly, because there are a number of unresolved type errors. Most of them should not be suppressed, but neither I nor others have get gotten around yet to fixing them. Some of them maybe should be suppressed, but neither I nor others have gotten around yet to verifying are reasonable to suppress. (For quite some time, the mypy step has step-level continue-on-error, which causes it not to fail the job.)

There's no connection between this and #2037 or #2038/#2039, except in the broad conceptual sense that this and #2038 share as a contributing factor that it's easy not to notice unanticipated new problems with mypy. However, just in case, I have verified that the effect of #2039 applies the same to 3.13t as to 3.13, by first testing this on a feature branch that had not integrated #2039, and then rebasing.

No change is needed in tox.ini, even separately from that not yet listing a py313t environment, because tox.ini as currently written does not pass a --python-version argument to mypy.

I plan to merge this once everything passes on CI, after also verifying again that the output is as expected.

Edit: The effect is as expected and intended. I'll just wait for the rest of CI to pass before merging.