fix(plugins): recover plugins stuck after an app ABI bump (#1380)

[datlechin]

Problem

After updating TablePro across a PluginKit ABI bump, an already-installed registry plugin (MongoDB, Cloudflare D1, etc.) becomes incompatible and the app behaves badly in two ways that look like the same "Plugin was built for PluginKit version N" error (#1380):

1. Connect path (app): on the first launch after the update, the stale bundle is rejected and reconciliation downloads the new one in the background. The connect path waited only for the initial load, not for reconciliation, so it threw pluginNotInstalled ("Plugin Not Installed") and a manual Install collided with the in-flight update. Users worked around it by quitting and reopening, which let reconciliation finish between sessions.
2. Registry data: every plugin's declared kit-14 binary in plugins.json actually shipped a kit-15 bundle. A user on app 0.44.0 downloaded it and the app rejected it on ABI validation, with no way to recover. The build always compiles current main, and the registry kit version was a workflow label, not read from the served binary.

Changes

Connect path (Part A)

• DatabaseDriverFactory.createDriver now awaits reconciliation when the type's plugin is installed-but-outdated, then re-checks the driver. If no compatible build exists, it throws PluginError.pluginUpdateUnavailable(reason:) carrying the reconcile reason ("A newer version of TablePro is required...") instead of the misleading "Plugin Not Installed" prompt.
• RejectedPlugin gains providedDatabaseTypeIds so a connect can map a database type to a stale-but-reconciling plugin. New PluginManager helpers: hasOutdatedRejectedPlugin(forTypeId:), outdatedReconcileReason(forTypeId:), awaitReconciliation(). A reconciliationActive flag bounds the wait to the first pass so a connect never blocks on a retry sleep.

Registry integrity (Part B)

• build-plugin.yml now downloads the published public asset and verifies its Info.plist matches the label before the registry is updated. The existing guard only checked the local build output; this checks the bytes the registry will actually point at, so a clobbered or stale asset can't poison the registry again.

Already applied (registry repo)

The poisoned kit-14 data was purged from TableProApp/plugins (plugins.json, commit 9c9715b on main): the 20 mismatched kit-14 binaries were removed, leaving each plugin with its genuine kit-15 binaries. Users still on 0.44.0 now get the honest "update TablePro" message instead of a failing download.

Test plan

• New cases in PluginManagerReconciliationTests cover the missing-vs-outdated decision and the reason surfacing.
• Manual: on a build with a bumped ABI, connect to a database whose plugin is updating. It should connect after a short wait, or show "update TablePro" when no compatible build exists, without needing a relaunch.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7b0340707d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".