Add Python 3.13 support

[bochinski]

Tracking issue

Closes flyteorg/flyte#6993

Why are the changes needed?

flytekit declares requires-python = ">=3.10,<3.13" and cannot be installed on Python 3.13. This PR adds 3.13 to the supported and tested versions. Python 3.14 is out of scope: flyteidl declares requires-python <3.14, so flytekit cannot be installed on 3.14 regardless of this repo.

What changes were proposed in this pull request?

• pyproject.toml: requires-python = ">=3.10,<3.14", 3.13 classifier. uv.lock regenerated (not used by CI); the lock was also behind pyproject.toml on master, so the diff additionally catches up flyteidl 1.16.4 -> 1.16.8 and the fsspec/gcsfs/s3fs bounds.
• PythonVersion enum and default image prefixes: add 3.13 (core, sqlalchemy and openai-batch images). Without it DefaultImages.find_image_for() raises ValueError on 3.13.
• CI: PRs run 3.13 only (a single version, as before with 3.12), nightly runs 3.10–3.13. On 3.13 pandas<2 is excluded (no wheels). The plugin matrix mirrors the 3.12 exclusions (not verified on 3.13; several of the underlying issues are closed by now) and adds duckdb (python_requires<3.13); mlflow stays excluded because its tests need tensorflow, which on 3.13 requires protobuf 5+. flytekit-onnx-scikitlearn failed on 3.13 in the first CI run (its onnx<1.18 pin has no 3.13 wheels) and is fixed by the last bullet instead of being excluded.
• dev-requirements.in: tensorflow on >=3.12 and torch on >=3.11, and the 3.12 skip of the extras job is removed (Support Python 3.12 tensorflow/tensorflow#62003 and Pytorch for Python 3.12 not available pytorch/pytorch#110436 are closed). protobuf<5 (and types-protobuf<5) is kept on <3.13 only: tensorflow releases with 3.13 wheels need protobuf 5+, and the reason for the pin ([Housekeeping] Add support for protobuf version 5 in flytekit flyte#5448) was fixed upstream. 3.10 and 3.11 resolve to the same versions as before. On 3.12 every job that installs this file now also gets tensorflow 2.19 and torch 2.14 (with CUDA wheels on linux), and numpy is capped to 2.1.x by tensorflow 2.19.
• Publish py3.13-* images.
• pytorch extras: torch.load(..., weights_only=False) for nn.Module and checkpoint objects, where the keyword exists. The default flipped to True in torch 2.6 and cannot unpickle those (this is also the current nightly 3.11 failure on master). Tensors keep torch's default. weights_only=False executes pickle code from the blob, the same trust model as FlytePickle.
• flytekit.lazy_import.lazy_module: for a dotted name, importlib.util.find_spec imports the parent packages, and if a parent's __init__ imports the requested module itself, lazy_module replaced that module with a lazy placeholder and it got executed a second time, producing a second set of class objects. skl2onnx>=1.19 does exactly that with skl2onnx.common.data_types, which is why flytekit-onnx-scikitlearn got the caps onnx<1.18 / skl2onnx<1.19 in [CI] Fix plugin errors #3257 ("shape must be a DataType"). The fix re-checks sys.modules after find_spec; a regression test covers it. The same duplication affected the spark, sqlalchemy and polars plugins (pyspark.sql.dataframe, pandas.io.sql, fsspec.utils) without a visible failure. With the fix the plugin's two caps are removed (they were coupled: skl2onnx 1.18 imports helpers that onnx 1.18 removed) and the plugin requires flytekit>=1.16.29 (assumed to be the next release, the first one containing the fix), so upgrading the plugin alone cannot pair a new skl2onnx with a flytekit that lacks the fix.

How was this patch tested?

Locally on Linux x86_64 with uv and docker.

• 3.13: make unit_test 1970 + 25 passed, make test_serialization 78411 passed, make unit_test_extras 128 passed (tensorflow 2.21 / torch 2.14 / protobuf 7).
• 3.12: make unit_test and make unit_test_extras pass (tensorflow 2.19 / torch 2.14 / protobuf 4.25).
• dev-requirements.in resolves for 3.10–3.13 on linux and 3.12/3.13 on windows and macos; every plugin dry-run resolves on 3.13 except mlflow and duckdb.
• flytekit-onnx-scikitlearn: the build-plugins job replayed locally (same install steps, including the forced numpy<2) passes on 3.12 and 3.13 with onnx 1.22 / skl2onnx 1.20 and with the previously pinned onnx 1.17 / skl2onnx 1.18. The new lazy_module test fails on master and passes with the fix.
• First CI run on the PR: 54 of 56 checks passed; the two failures were the onnx-scikitlearn plugin job on 3.13 (fixed above) and integration (3.13) on test_signal_approve_reject, a signal-timing flake unrelated to this PR (the same job passes on master; Bump timeout in integration tests to 10 minutes #3146 documents the flakiness).

Check all the applicable boxes

• I updated the documentation accordingly. (no docs mention supported versions)
• All new and existing tests passed.
• All commits are signed-off.

Related PRs

Supersedes #3401 and #3368.

🤖 Generated with Claude Code

[bochinski]

CI finished with two failures, so one more commit went in:

• build-plugins (3.13, flytekit-onnx-scikitlearn) failed because the plugin's onnx<1.18 pin has no 3.13 wheels. The root cause of that pin turned out to be a bug in flytekit.lazy_import.lazy_module: a lazily requested submodule that the parent package already imports got executed twice, which broke the plugin with skl2onnx>=1.19. The last commit fixes lazy_module (5 lines plus a regression test), removes the plugin's onnx/skl2onnx caps and gives it a flytekit>=1.16.29 lower bound. Details are in the commit message and the updated description.
• integration (3.13) failed on test_signal_approve_reject with a signal timeout; the same job passes on master and the test is a known flake (Bump timeout in integration tests to 10 minutes #3146). A re-run should be enough.

One thing I cannot decide: the flytekit>=1.16.29 bound is a guess and assumes the next release is the first one containing the fix. If the next version will be numbered differently, please tell me and I'll adjust it.

Happy to split the lazy_module fix into its own PR if you prefer that scope. In that case this PR would exclude flytekit-onnx-scikitlearn from the 3.13 plugin matrix, and the follow-up PR would carry the fix and re-enable the plugin.