feat(findings): replica_identity_missing — a published table that can't be updated

[lofoneh]

What

A table published for UPDATE or DELETE needs a replica identity so the subscriber
can find the row. Without one, Postgres refuses the write:

ERROR: cannot update table "events" because it does not have a replica identity
       and publishes updates

Reads and INSERTs keep working, so you don't find out at deploy time — you find out
on the first UPDATE after the migration. This adds a finding for it.

It reads the catalog only — pg_publication, pg_publication_tables, pg_class,
pg_namespace, pg_index — so it's schema scope and pgbot lint
catches it on an empty CI database. Insert-only publications need no identity and are
skipped. I deliberately didn't flag every table without a primary key — that fires on
append-only tables and partitions where it's intended.

Note: #46 also bumps the schema to 1.4.0. Whichever lands second needs a renumber, and
I'm happy to rebase.

Verification

On PG 18.6:

• The integration fixture creates the publication, confirms the UPDATE really fails,
  then asserts the finding. Adding a primary key clears both.
• The schema-profile acceptance test still sees zero findings on a sound schema.
• Doc-verify runs the new verify query.
• pgbot lint exits 2 with the finding, and cleanly once there's a key.
• scripts/gate.sh green.

Checklist

• scripts/gate.sh passes (builds HEAD, not just the working tree)
• New SQL is read-only; no EXPLAIN ANALYZE; findings stay deterministic (computed in Go)
• No PII enters a model.Context / --json / the store — relation and publication names only
• --json change is additive, model.SchemaVersion bumped + schema regenerated
• A new finding has a docs/findings/<id>.md page + catalog entry

[lofoneh]

I ran this against a wal_level=logical server and established ground truth by running the real UPDATE on each table first, so the report is checked against what Postgres does rather than what I assumed:

table	real UPDATE	reported
primary key	succeeds	no
no primary key	fails	yes (d)
REPLICA IDENTITY NOTHING	fails	yes (n)
identity index dropped	fails	yes (i)
insert-only publication	n/a	no
partitioned, publish_via_partition_root	partition write fails	yes (root)

The dropped-index case is the one I wouldn't have guessed: after DROP INDEX, relreplident stays i with nothing behind it, so the table quietly stops accepting updates. FOR ALL TABLES and FOR TABLES IN SCHEMA both expand correctly, and a table outside the published schema isn't flagged. With every case fixed, lint exits 0.

[alexshapalov]

@lofoneh, tnx, pls resolve conflicts

[lofoneh]

@alexshapalov , Conflicts resolved. #38 took 1.4.0, so this is 1.5.0 now and the schema's regenerated.