coverage is the fourth task that compiles the pgrx crate, and the only one #813 never provisioned

[CarlAllenn]

Defect

pgrx-env.sh says at the top of itself:

Three tasks compile a pgrx extension — lint:pg-clippy, test:pgrx
and fix:rust's extension pass

There is a fourth, and it arrives the moment a repository does what #813
asks. coverage:check and coverage:report run cargo llvm-cov --workspace, held off the pgrx crate only by the repository's
COVERAGE_EXCLUDE — the exclusion that dies with CLIPPY_EXCLUDE
(release-lab#268, and #813's own ruling that the pair go together). The
coverage tasks are the one consumer of the crate that neither derives the
gate surface nor sources pgrx-env.sh: they read COVERAGE_EXCLUDE, and
that is all they read.

Measured on release-lab at canon v1.61.1, both exclusions deleted and the
five Postgres majors pinned:

1: clang diagnosed error: .../clang/17/include/inttypes.h:24:15:
   fatal error: 'inttypes.h' file not found
Location: .../pgrx-bindgen-0.19.2/src/build.rs:898:10
error: process didn't exit successfully: `cargo test --tests ... --workspace --locked`
[coverage:check] ERROR task failed

That is exactly the failure org_pgrx_darwin_flags exists to prevent,
reached by the one path that never calls it. Exporting the same two
variables by hand and re-running 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 the un-re-derived floor
(56.8% is below the derived floor 85.5%, which is #268's own
coverage:adopt step). So the crate is measurable and the gap is
provisioning.

macOS is where it is fatal today; the runner is not exempt. On Linux the
SDK correction is a no-op, but org_pgrx_init is not: nothing has
registered a pg_config with pgrx, so pgrx-bindgen on a cold runner has
no server headers to parse. The reason release-lab could be carried
through by hand is that test:pgrx had already populated PGRX_HOME on
this machine — a state a fresh gate does not have.

This is the shape #813 exists to end, one task further along: a check
that reports a number for a workspace it could not compile, or does not
run at all.

Decided build

coverage:check and coverage:report provision the same way the other
three do, from the same two files, so there is still one copy of the
knowledge:

• derive the surface with gate-surface.py rather than trusting
  COVERAGE_EXCLUDE — the pgrx crate is DERIVED everywhere else in the
  belt and this is the last place a repository still declares it
• when the surface names an extension, . pgrx-env.sh, then
  org_pgrx_darwin_flags and org_pgrx_init over pgrx-postgres.py,
  guarded on there being one so a repository without an extension pays
  nothing — the lint:msrv shape verbatim
• pgrx-env.sh's header count goes from three to four in the same
  commit; it was true when written and a comment that counts is a comment
  that can go stale

Rejected, recorded: leaving COVERAGE_EXCLUDE alive for pgrx crates.
That is CLIPPY_EXCLUDE under a better name, and it would mean the
org's coverage floor is derived from a surface that silently omits an
entire published artifact class.

Canon consequence

Belt-only. No repository change beyond the exclusion deletions those
repositories are already making, and the floors they re-derive
afterwards will then include the extension.

Done when

• coverage:check compiles and measures a pgrx extension on a repository
  with no COVERAGE_EXCLUDE, proven on the runner and not only locally
• the same run is green on macOS from a cold PGRX_HOME
• pgrx-env.sh names four tasks
• release-lab#268 can delete COVERAGE_EXCLUDE and re-derive
  .coverage-floor in one commit without a hand-exported variable

Sequencing

Blocks the COVERAGE_EXCLUDE half of release-lab#268 and of edtf's
sibling adoption; the CLIPPY_EXCLUDE half is unaffected. Found
2026-08-24 while doing release-lab#265. Refs #813, #687.