fix(api): reconcile plugin tables on upgrade and skip a missing one on uninstall

[zscontributor]

Note on scope: develop was 17 commits behind main when this was opened, so this PR carries that backlog plus the 2 new commits described below. The new work is feat(plugins): enhance plugin upgrade handling… onward — everything before it is already on main and already deployed.

Three faults found while shipping a plugin version that introduces a new table. Each one made the previous one harder to see.

1. An upgrade of a RUNNING plugin never ran its schema

ensurePluginTables + setup() run on activation, and nobody activates a plugin that is already active — the admin only activates if (!isActive). Installing a new version over a running one swapped versionId and nothing else, so a table the new version declares was never created.

What the operator saw: the new admin screen answered 404, because the generic plugin resource page turns any 403/404/500 from the endpoint into notFound() — a missing table is indistinguishable from a missing screen.

install now runs the same two steps activation runs when the row was ACTIVE and the version changed. Both are idempotent (CREATE TABLE IF NOT EXISTS, ADD COLUMN IF NOT EXISTS, a setup() that seeds only what is missing) — this is dbDelta on upgrade. If the new version cannot start, the install stands, the plugin is FAILED, and its own message comes back in error rather than a clean "ok" the operator discovers is a lie on the live site.

2. Uninstall — the way OUT of a broken install — needed the tables to exist

purgePluginSiteData runs DELETE for every table the manifest declares. Against a table that was never created that is 42P01, surfaced as "Internal server error" with the plugin still installed. It now probes for the table and skips a missing one: nothing to delete is not a failure, it is the answer.

3. …and the first version of that probe was a 500 of its own

SELECT to_regclass($1) returns type regclass, which Prisma's pg adapter cannot deserialize (UnsupportedNativeDataType / P2010). The NULL test now happens in Postgres and only a boolean crosses the wire. Mocked unit tests cannot catch a driver-level type fault, so the test asserts the SQL shape instead, and the query was run against a real database.

Also here

admin.error.* — a Server Action id is baked into the page at build time, so a tab left open across a deploy posts an id the new build has never heard of. Next's message reads like a fault in the software; it is neither, and Retry is the most dangerous button on that screen — it re-sends a dead id from stale JavaScript for an action that has usually already run (the uninstall above completed; only the response path failed). The boundary now recognises it and offers a full reload.

Tests

cms-api 745, admin-web 323, i18n 118 — green; every package typechecks.

• plugins.controller.test.ts — upgrade-while-active reconciles; an inactive install is left alone; same version re-consented does nothing; a failing setup marks FAILED and reports.
• plugins.service.test.ts — purge deletes only this site's rows; skips a table that was never created; asks Postgres for a boolean, never for an oid.
• error.test.tsx — stale action offers reload and never calls reset(); an ordinary failure still retries and still shows its message.