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 two floors it caught.

1. The asyncpg band was too coarse

The existing comment has the right idea and the wrong boundary. asyncpg ships no cp312 wheel before 0.29.0 either, and asyncpg>=0.28; python_version < '3.13' covers 3.12:

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

Split at every interpreter where upstream actually added a wheel — 0.29.0 for cp312, 0.30.0 for cp313, 0.31.0 for cp314:

"asyncpg>=0.28; python_version < '3.12'",
"asyncpg>=0.29; python_version == '3.12'",
"asyncpg>=0.30; python_version == '3.13'",
"asyncpg>=0.31; python_version >= '3.14'",

2. The SQLAlchemy floor was untestable

sqlalchemy[asyncio]>=2.0.18 is not a claim this repo can stand behind. advanced-alchemy is in the dev group, and every advanced-alchemy release ever published requires sqlalchemy>=2.0.20 — 0.1.0 already did. The suite could never have run against 2.0.18.

Left alone this is worse than a wrong floor, because the job would have looked right: it silently resolves 2.0.20 and reports the 2.0.18 claim as verified. Raised to what the tests actually exercise:

"sqlalchemy[asyncio]>=2.0.20; python_version < '3.13'",

The 2.0.31 bound from 3.13 up is unchanged and correct — verified, it is what the job installs there.

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.

--no-build: a floor reachable only by compiling an sdist is not a floor a user installing a wheel can reach — which matters here, since asyncpg's sdist needs a C toolchain. --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 job carries the same postgres service and DISABLE_SQLALCHEMY_CEXT_RUNTIME handling as pytest, for the same reasons.

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; before this the leg could not start pytest. advanced-alchemy is floored at 1 — the value is immaterial to the SQLAlchemy question above, since the >=2.0.20 requirement is constant across its history.

Verification

Run locally on all five interpreters at the floors, against a real postgres: tenacity==8.4.1, sqlalchemy==2.0.20 / 2.0.31, asyncpg==0.28.0 through 0.31.0 as the bands dictate, 40 passed on each. Resolved-newest path re-checked with just install && just lint-ci and pytest at 100% coverage. Local runs are macOS/arm64; CI is the verdict on manylinux wheel coverage.