docs(ci): correct what the lowest leg is said to guard

[lesnik512]

One line of comment in _checks.yml. No job behaviour changes.

The claim that was wrong

# them: `pytest` and `scheduled-dep-check` both resolve highest. That is how
# 0.13.2 shipped `faststream>=0.7.1` and stayed green until 0.7.6 broke a user.

That incident is real, but it is not an argument for this job — it is the opposite of one.

$ git show 0.13.2:pyproject.toml
dependencies = [
    "faststream>=0.7.1,<0.8",
    ...
]

0.7.6 is inside >=0.7.1,<0.8. The break came in at the top of the range, from resolving newest, which pytest and scheduled-dep-check already do — and a leg resolving lowest-direct would have installed 0.7.1, the version that was working, and passed. This job would not have caught it.

The floor moved to 0.7.6 in #182, and reading that commit confirms the direction: adapting to the new TestBroker.__init_subclass__(broker=...) hook made import faststream_outbox fail on 0.7.5, so the floor was raised to say so. The floor followed the code; it was not caught going stale.

Leaving it in place is worse than a stray inaccuracy — it is the comment a reader consults to decide whether the job is worth its matrix, and it argues for the job with an incident the job is blind to.

The replacement

This repo's own floor failure, the one #186 fixed:

# `sqlalchemy[asyncio]>=2.0` stayed declared after 3.13 made it fail at import.

Verified by running it — 3.13, wheel-only:

$ uv pip install --no-build 'sqlalchemy[asyncio]==2.0.0'
 + sqlalchemy==2.0.0
$ python -c 'import sqlalchemy'
AssertionError: Class <class 'sqlalchemy.sql.elements.SQLCoreOperations'> directly
inherits TypingOnly but has additional attributes {'__firstlineno__', '__static_attributes__'}.

It is a better example than the one it replaces on three counts. It is this repo's, not a sibling's. It is the failure mode only this leg reaches — pytest resolves SQLAlchemy 2.0.4x and never sees it. And it installs cleanly and then fails, so it is not covered by a wheel-coverage check either; you have to resolve low and actually run something.

The two surrounding sentences are untouched, and the comment stays the same length.

Verification

just install && just lint-ci && just test-ci against a local postgres 17: clean, 624 passed, 100% coverage. The workflow still parses and the lowest job's matrix is unchanged (3.11–3.14).

Noticed nearby, not fixed here

Two things I left alone so this stays a one-line diff, both worth a separate look:

• pyproject.toml carries # (2.8.0 carries pydantic-core 2.20.0, which has none) about cp313 wheels, from ci: resolve the floors wheel-only; fix the 3.13 pydantic floor #190. pydantic-core 2.20.0 ships 11 cp313 wheels — every platform except macosx_11_0_arm64, which 2.20.1 adds. The >=2.8.1 floor is right, but for a macOS-arm64 reason, and on ubuntu-latest 2.8.0 would have installed. The comment overstates it.
• docs/tutorials/first-outbox-app.md:43 still shows + faststream==0.7.1 in sample install output; the floor has been >=0.7.6 since chore(deps): adapt to faststream 0.7.6 and raise its floor #182.

[github-actions]

Benchmark gate

✅ gate passed

scenario	msg/s	delete/msg	WALrec/msg	WALB/msg	fpi	upd	del	dead_tup
consumer/w1/b10	910	1.000	6.79	918	242	5000	5000	10000
consumer/w1/b100	932	1.000	6.83	920	243	5000	5000	10000
consumer/w2/b10	1072	1.000	6.81	970	242	5000	5000	10000
consumer/w2/b100	1258	1.000	6.78	996	263	5000	5000	10000
consumer/w4/b10	930	1.000	6.68	922	243	5000	5000	10000
consumer/w4/b100	1421	1.000	6.87	1038	243	5000	5000	10000
consumer/w1/b100/tfbs100	4529	0.010	6.07	1116	243	5000	5000	10000
producer/w1/b100	2065	0.000	3.04	584	0	0	0	0

Gated (fails the build): delete_calls + tuple counters (upd/del/ins) + the producer's insert_calls, exact; select_calls within +2; wal_records within a 10% band. msg/s, WAL bytes and total calls are informational (timing/FPI noise).