fix(plugins): update incompatible plugins quietly after an app ABI bump (#1322)

[datlechin]

Problem

After a PluginKit ABI bump (registry plugins moved 13 to 14 across the 0.43.x updates), users who had plugins installed on an older app version saw a "could not be loaded" notification on launch and an alert when updating, even though the registry already carried compatible builds. Reported in #1322. Two earlier fixes (#1343, #1371) handled the happy path, but the notification still fired too early and one registry entry was unusable.

Root cause

1. The reconciliation loop sent the rejected-plugins event (which drives the failure notification) after every pass, including while a retry was still scheduled or the registry manifest had not loaded yet. Users saw a failure message before reconciliation had actually finished.
2. The DynamoDB registry entry carried a binary with pluginKitVersion: null, which can never match the app's exact-version lookup, so it stayed permanently rejected and kept triggering the notification.
3. A plugin a user downloaded and dropped in by hand kept its quarantine flag, so macOS Gatekeeper blocked it with no clear path forward.

Fix

• Reconciliation now notifies only at a terminal state. While retries are pending, including when the registry is briefly unreachable at launch, it stays silent. Permanent failures (no compatible build, app too old) stop retrying and surface an actionable message; transient failures retry quietly.
• Staged updates during reconciliation are treated as success-pending and apply when connections close.
• installLooseBundle strips quarantine after verifying the signature, so a hand-installed plugin loads without the Gatekeeper dead end.
• update-registry.py drops binaries without a concrete integer pluginKitVersion, so a null entry can no longer shadow a valid build.
• Reworded the outdated-plugin message to drop the misleading "Please update the plugin" line, since reconciliation does the update.

Follow-up (registry, separate repo)

The live TableProApp/plugins manifest still has the DynamoDB null binary. Re-release the registry plugins (scripts/release-all-plugins.sh 14) so the hardened script drops it and DynamoDB resolves on app v14.

Tests

• A valid binary is still selected when a null-kit binary is present (the DynamoDB case).
• Permanent vs transient reconciliation error classification.
• A python test for the registry prune (drops null, keeps the two newest kit versions).

Localizable.xcstrings is left out of this PR; the new strings extract on the next build.