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.