ci: resolve the declared dependency floors on every matrix entry

[lesnik512]

Adds the floors job the org standard requires (standard.md §7), following modern-di-fastapi#56, and fixes the pydantic floor it caught.

What the job found

faststream>=0.7 itself holds — faststream 0.7.0 passes the suite on every interpreter. What did not install is the pydantic it drags in. pydantic-core ships no cp313 wheel before 2.20.1 (pydantic 2.8.1) and no cp314 wheel before 2.35.0 (pydantic 2.12), and the floor resolution landed on pydantic 2.7.4:

error: Distribution `pydantic-core==2.18.4` can't be installed because it is
marked as `--no-build` but has no binary distribution

On 3.13, 3.14 and 3.14t the declared floor could not be installed from wheels at all. Anyone pinning low on a current interpreter needs a C toolchain to get this package, which is not what a floor is supposed to mean. Bounded per interpreter, in the shape modern-di-aiogram already uses for the same dependency:

"pydantic>=2.8; python_version == '3.13'",
"pydantic>=2.12; python_version >= '3.14'",

faststream still resolves to 0.7.0 on all six, so the shipped floor is unchanged and now actually exercised.

Why the job exists

pytest resolves every dependency at its newest, so the bottom of each declared range ships unexercised. This job resolves direct dependencies at their floors, wheel-only, on every entry of the same matrix pytest uses, and runs the suite against them. Wheel coverage is per interpreter — 3.10 through 3.12 were fine throughout — which is why the job runs on every entry rather than one.

--no-build: a floor reachable only by compiling an sdist is not a floor a user installing a wheel can reach. Without it the resolver builds one and the job reports success. --no-install-project is mandatory alongside it — --no-build would otherwise refuse to build this project too, and the tests import it from the checkout.

The dev-group floors

uv sync --resolution lowest-direct treats an unbounded name in [dependency-groups] as "any version" and resolves it to that project's first-ever release. These are lower bounds on the test harness only. faststream[nats] is deliberately left unbounded there: it is a runtime dependency, and a harness bound would override the declared floor and test the wrong version. The resolved-newest path is unchanged.

Verification

Run locally on all six interpreters at the floors: faststream==0.7.0 on each, 20 passed. Resolved-newest path re-checked with just install && just lint-ci && just test-ci. Local runs are macOS/arm64; CI is the verdict on manylinux wheel coverage.

pydantic 2.8.1 rather than 2.8: pydantic-core 2.20.0 ships a manylinux cp313 wheel but no macOS arm64 one, and 2.20.1 — pydantic 2.8.1 — is the first that covers both. A floor that holds only on the platform CI happens to run is not a floor.

[lesnik512]

Superseded by #63, which landed the same job, and by #64 for the one thing #63 leaves open.

Two reasons to close rather than rebase:

The pydantic bound here was aimed at the wrong layer. This PR bounded pydantic in [project.dependencies]. The resolution failure it was reacting to was real, but it did not come from the shipped floor — it came from the lint group's unbounded typing-extensions. uv runs one resolution across every group, so a low typing-extensions holds pydantic back to a build whose pydantic-core ships no wheel for the interpreter under test. #63 fixed it in the group where the unbounded name actually lives, which is the right place: a runtime bound would have constrained every user's pydantic to pay for a CI-only artifact.

Verified before closing — clean 3.13, 3.14 and 3.14t venvs, each:

uv pip install --no-build --resolution lowest-direct 'faststream>=0.7,<0.8' 'modern-di>=3,<4'

installs on all three, resolving faststream==0.7.0 with pydantic==2.13.5. The declared floor installs wheel-only as shipped.

The rest is already in main. #63 has the job, --no-build, --no-install-project, and the dev-group floors. What it does not have is the sixth matrix entry: pytest runs six, the floors leg runs five, and 3.14t is uncovered. #64 adds that one line.

Also noted and deliberately not carried over: §7's job table names the job floors and #63 named it lowest. That is a naming call across the org, tracked separately rather than settled in a drive-by.