harness fidelity: the local provider role is a superuser, which is why the whole provider-vs-owner class only ever surfaces at night #728

Every nightly-rls-failure we have filed for a real bug has been one shape: something that needs privileges the nightly's provider role does not have. #383 (TRUNCATE), #637/#688 (CREATE TRIGGER), #717 (EXECUTE on a function revoked from PUBLIC). Each was invisible locally and in PR CI, and each cost a red nightly plus a debugging round-trip.

The reason is not "Neon is different". It is that our two lanes do not model the same database:

So the local lane structurally cannot fail any of these, and lint rules R1/R5 exist to paper over the gap by pattern-matching the shapes we have already been bitten by. That works — but only for shapes we have already seen, which is why R1 had to be generalised twice (TRUNCATE → all owner-only DDL) and then could not see #717 at all (a plain select fn(), not DDL).

Proposal

Close the fidelity gap instead:

1. Move local and the test-db CI job to PostgreSQL 17 (ci.yml currently pins postgres:14 in two places).
2. Make the local provider a non-superuser matching the measured remote shape:

create role webhook_provider login nosuperuser bypassrls createdb;
grant pg_read_all_data, pg_write_all_data to webhook_provider;         -- DML without ownership
grant webhook_owner to webhook_provider with inherit false, set false;  -- PG16+ syntax

3. Point providerUrl at that role instead of postgres.

Sequencing note: WITH INHERIT FALSE / SET FALSE is PG16+ syntax, so the version bump is a prerequisite, not an optional companion. (On PG14 the same effect is reachable via a NOINHERIT role attribute — verified working as a local simulation — but that is a workaround, not parity.)

Why it is worth the day

A throwaway simulation of exactly this shape reproduced the #717 denial and the #383 TRUNCATE denial locally in ~1.4s, and was mutation-checked (flipping the role to INHERIT makes both denials disappear). That is the entire historical bug class, caught on every PR, with no shared resources, no credentials, and no nightly round-trip.

It also lets us re-measure whether the lint rules are still carrying their weight, and whether a real-Neon debug loop has any residual value at all (today's evidence says close to none once this lands).

Risks to work through

• Tests that legitimately need a superuser (e.g. rls.test.ts binds a root handle explicitly "to prove trigger-level immutability") must keep one — the change is to the provider handle, not to remove superuser access entirely.
• Anything that breaks under the new provider is, by construction, a latent nightly failure — but each needs triaging rather than blanket-fixing.
• PG14→17 may surface unrelated behaviour differences; worth landing the version bump on its own first.