the canon pin reds until the lab-pg exclusions die in the same commit

[CarlAllenn]

Defect

Renovate PR #266 (canon → v1.61.x) is red and cannot merge. Measured on gate run 32687779782, the only failing task:

lint:gate-surface: the gate does not compile what the publish path builds
  lab-pg@0.28.1 is built by the publish path and held out of the gate by
  CLIPPY_EXCLUDE — delete the exclusion; a crate the gate cannot compile
  is a crate the release finds out about

lint:gate-surface is new in the belt this repo is bumping to, and it arrived WITH its enabling mechanism: canon #813 closed 2026-08-24 02:44, putting pgrx compilation and a belt-provisioned postgres into the gate. The exclusion's recorded reason (mise.toml:13-17 — mutually exclusive pg14..pg18 features under --all-features, and no live postgres on the runner) was true when written and is now stale: the belt provides what it worked around. So this is not a lint colliding with a legitimate exclusion; it is a lint correctly reporting an exclusion that outlived its cause. Same class as stele#248 — the red arrives inside a dependency PR, the worst place to meet a policy change.

Decided build

ONE commit amending Renovate PR #266 — never a second PR — carrying the pin bump and the exclusion removal together:

• delete CLIPPY_EXCLUDE = "lab-pg" (mise.toml:17) and COVERAGE_EXCLUDE = "lab-pg" (mise.toml:12) — the coverage twin dies for the same reason, per #813's ruling that the lab-pg exclusion dies with it; leaving one of the pair is a second definition of the same stale fact
• re-derive .coverage-floor in the same commit through mise run coverage:adopt, because the measured surface changes when lab-pg enters it — the floor is derived state and a hand-typed number is drift the checker refuses
• if lab-pg's tests or clippy do not in fact pass under the belt's provisioned postgres, STOP and report rather than re-adding an exclusion: that would be a defect in #813's mechanism, filed against the canon, not worked around here

Rejected, recorded so it is not re-proposed: keeping either exclusion with a dated exception (the cause is gone — an exception with no live reason is an excuse); pinning the canon back.

Canon consequence

None if lab-pg compiles and tests under the belt's postgres. If it does not, the finding belongs to canon #813's mechanism and is filed there with the failing output.

Done when

• PR chore(canon): update first-party canon #266's gate is green, proven by the run, with pin + both exclusion deletions + the re-derived floor in one commit, no second PR
• grep -n 'lab-pg' mise.toml shows no exclusion declarations
• .coverage-floor carries a fresh derivation record whose measurement includes lab-pg

Sequencing

Blocked by nothing — canon #813 has landed. Before any further canon bump lands here. Found 2026-08-24 by the stele batch orchestrator while reading consumer reds after the batch's proof pass (ledger #262).

[CarlAllenn]

Blocked. Neither half can land green, and the reason is not this
repository's. Taking this issue's own instruction — "if lab-pg's tests
or clippy do not in fact pass under the belt's provisioned postgres, STOP
and report rather than re-adding an exclusion" — with the amendment that
clippy and the tests do pass. What fails is two mechanisms on either
side of them. Measured on main at 09ddd36 (post-#269) with the canon
belt at v1.61.1, one change at a time.

1. The decided build is missing a step: the repository must also pin
the Postgres. Deleting CLIPPY_EXCLUDE alone does not make
lint:pg-clippy run — it makes it fail:

pgrx-postgres: the crate declares a major this repository does not pin
  pg18 is declared by the crate's features and no Postgres 18.x is pinned
  pin them in this repository's mise.toml, beside cargo-pgrx:
    "aqua:theseus-rs/postgresql-binaries" = ["18.6.0", "17.11.0", ...]

.github#813 pins the Postgres in the REPOSITORY, deliberately, so the
belt does not cost every repo in the org ~200M for a server it never
runs. So the commit this issue describes needs a fourth line:

"aqua:theseus-rs/postgresql-binaries" = ["18.6.0", "17.11.0", "16.15.0", "15.19.0", "14.24.0"]

Latest per major, from mise ls-remote, beside cargo:cargo-pgrx as the
remedy says.

2. Adding that line reds lint:subject-budget — canon .github#916.

lint:subject-budget: 1 of 19 dependencies would mint a subject past 72 columns

   80 cols (over by 8)  aqua:theseus-rs/postgresql-binaries
        from mise (mise.toml)
        chore(deps): update aqua:theseus-rs/postgresql-binaries to 9999999999 [SECURITY] (#999999)

The remedy the lint prints is a commitMessageTopic in the canon's
default.json, which is not a change this repository can make. #813's
own instruction is therefore unfollowable by any repo until the canon
ships one — filed with the rule and its measurement: with
"commitMessageTopic": "postgresql-binaries" in default.json, this
repo reports 19 dependencies, every subject the owned template can mint
fits 72 columns. Because default.json is consumed by tag, that fix
also needs a canon release before it reaches here.

3. Deleting COVERAGE_EXCLUDE puts lab-pg into a task nothing
provisioned — canon .github#917. coverage:check and
coverage:report are the fourth thing that compiles the extension and
the only one that neither derives the gate surface nor sources
pgrx-env.sh (whose header still says three tasks). It dies in
pgrx-bindgen:

1: clang diagnosed error: .../clang/17/include/inttypes.h:24:15:
   fatal error: 'inttypes.h' file not found
   at pgrx-bindgen-0.19.2/src/build.rs:898:10
[coverage:check] ERROR task failed

— which is precisely what org_pgrx_darwin_flags exists to prevent,
reached by the one path that never calls it. Exporting the same two
variables by hand carried it all the way through: lab-pg compiled, its
#[pg_test] ran under llvm-cov (test tests::pg_answers ... ok), and
the only remaining failure was coverage:check: rust: 56.8% is below the derived floor 85.5% — i.e. this issue's own coverage:adopt step, and
nothing worse. So the crate is measurable and the gap is provisioning
alone. Note the runner is not exempt: the SDK correction is a no-op on
Linux, but org_pgrx_init is not, and the only reason a hand-export
sufficed here is that test:pgrx had already populated PGRX_HOME on
this machine.

What is unchanged. The clippy debt this issue's third bullet worried
about is gone: #265 is done and merged (#269), lint:pg-clippy is
clean at every group and test:pgrx is green at pg14 through pg18. No
exclusion was re-added and none should be.

Sequencing, revised. Blocked by .github#916 (the CLIPPY_EXCLUDE
half) and .github#917 (the COVERAGE_EXCLUDE half), both of which need a
canon release to reach this repo. When they land, the commit amending
#266 is: pin bump + both exclusion deletions + the Postgres pin line +
coverage:adopt, still one commit and still no second PR.