Require a lower bound on every dependency in pyproject.toml

[potiuk]

Adds a check-dependency-lower-bounds prek hook that fails when a dependency in any pyproject.toml has no lower bound. It covers the four tables where the unbounded requirements fixed by hand in #71324 were hiding: project.dependencies, project.optional-dependencies, dependency-groups and build-system.requires.

Two kinds of requirement are exempt: uv workspace members, which resolve from the checkout rather than PyPI, and direct URL requirements, where the URL already names the artifact. Without the workspace exemption the hook would report 922 false positives.

Six violations survived those exemptions across all 139 tracked pyproject.toml files and are fixed here — python-dateutil in the Python client, and the five pydantic-ai-slim extras in common.ai, bounded at the >=2.0.0 that #71324 already gave the same package in that provider's dev group. uv.lock and providers/common/ai/docs/index.rst are the regenerated consequences; the lock also picks up four metadata lines from #71324 itself, which merged without a relock.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

[potiuk]

All resolved @Lee-W except the python req

[Lee-W]

I kinda like it to be relaxed and already suggested it for a few times on different PRs already 🤔

We can still update the lowest python version all at once when relaxed. but I'm not going to block this PR.

[potiuk]

We can still update the lowest python version all at once when relaxed. but I'm not going to block this PR.

Problem with relaxing is also that prek hooks are pretty "sensitive" to Python version - for example AST might have some changes, in different Python versions, or MyPY will work differently or. ...... (there were multiple cases in the past.

And a bit of a problem here as well that this introduces "works-for-me" syndrom if people are using different Python versions in CI and locally - the >=3.10.<3.11 has two properties:

a) prevents this works for me
b) uses "lowest-common-denominator" - which is the same as Python version - 3.10 all PRs use by default (vast majority of PRs use 3.10 builds only - with the assumption that breaking changes in our code are rare and will be detected in canary. Surely we could run prek hooks with 3.14 consistently as well (but then for example there will be a chance that they will not work in the breeze 3.10 image that is used in most tests - and in codespaces or other places where devcontainers are used - and people who use devcontainers run prek hooks inside their default CI image.
c) it might also confuse people when to use and when not to use Python 3.14 syntax

[github-actions]

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-3-test

You can attempt to backport this manually by running:

cherry_picker cf4c769 v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.