docs(standard): require a floors job that resolves the declared dependency floors

[lesnik512]

Adds floors to section 7's job table: a job that resolves every direct dependency at its declared
floor, wheel-only, on every matrix entry.

Why

A declared floor is a claim that the package installs and works against that version, and today
nothing in the org tests it. just install runs uv lock --upgrade, so pytest resolves
everything at its newest on every run, on both entry points. The bottom of every declared range
ships unexercised.

It rots there, and two repos have already been bitten:

• compose2pod#126: a PyYAML floor that
  could not install on 3.14.
• faststream-outbox#190: a
  pydantic>=2 floor that no cp313 wheel satisfies below pydantic 2.8.1. Found the same day the
  job was made wheel-only, on a repo whose gate had already been green for two PRs.

Three repos invented a gate for this independently (compose2pod, faststream-outbox,
lite-bootstrap). That is the usual sign it belongs in the standard.

What the standard does and does not fix

It fixes the obligation and two properties, because both are things a repo gets silently wrong:

• Wheel-only. Without --no-build (or --only-binary naming the offender) the resolver
  compiles an sdist and reports success, so the job passes on a floor no wheel user can reach.
  This is exactly what hid the pydantic floor above.
• Every matrix entry. Wheel coverage is per interpreter. Two interpreters that resolve the same
  versions can still disagree on whether those versions install, which is the whole point of a
  marked floor.

It deliberately does not fix the YAML. The three existing gates differ for real reasons:
lite-bootstrap cannot run pytest at the floors (its conftest.py hard-imports optional
dependencies the floor target omits) so it smoke-imports per extras group; compose2pod scopes
--only-binary to PyYAML and drops 3.14t because no PyYAML ships a cp314t wheel;
faststream-outbox runs the full suite under uv sync --no-build. Any single mandated snippet
breaks two of the three. This is also the position section 7 already takes on a shared workflow
(#95).

One thing this overrules

lite-bootstrap runs its gate from scheduled.yml only, on the recorded grounds that
lowest-direct resolves transitive dependencies at their newest, so an upstream release can turn
it red for reasons no PR caused. That is true, but it does not distinguish this job from pytest:
install upgrades the lockfile, so pytest is exposed to the same upstream churn on every PR, and
the org already accepts that. The standard therefore says floors runs from both entry points, and
lite-bootstrap changes when the sweep reaches it. Say so here if you would rather keep it
scheduled-only and I will invert the rule instead.

Scope this creates

The job table is core, so this makes 20 repos non-conformant until swept: the 12 modern-di-*,
db-retry, httpware, semvertag, eof-fixer, faststream-redis-timers,
faststream-concurrent-aiokafka, plus reconciling the three that already have a gate. modern-di
declares no dependencies and needs nothing; that-depends is exempt from the core; chat-app and
the two templates publish nothing and have no _checks.yml.

Expect first runs to go red. A red is a floor raise in pyproject.toml, which only helps future
installs: already-released versions keep the wrong floor.

Verification

uv run mkdocs build --strict clean, uv run pytest 132 passed / 29 skipped. Both new links
resolve; neither matches the offline gate's remap pattern, so links.yml covers them weekly.