ci(plugins): give the load check the framework it dlopens against

[datlechin]

All 12 plugin releases for v0.68.0 failed at Verify the built bundles load. The plugins are fine; the check is wrong.

What fails

✗ BeancountDriver: dlopen(.../BeancountDriver.tableplugin/Contents/MacOS/BeancountDriver, 0x0006):
  Library not loaded: @rpath/TableProPluginKit.framework/Versions/A/TableProPluginKit
  Reason: [(no such file, not in dyld cache) (no such file) ]

The step unzips the distribution zip into an empty mktemp -d and points verify-plugin-loads.sh at it. That script sets DYLD_FRAMEWORK_PATH to the directories it is given, on the stated assumption that the app frameworks "sit beside them in the products directory". In a distribution zip nothing sits beside the plugin: ditto -c -k --keepParent archives the bundle alone. So dyld cannot resolve the framework and every plugin fails.

The failure text says a removed PluginKit requirement is the usual cause, which is what this looks like and is not what it is. scripts/check-pluginkit-abi.sh v0.67.1 reports the PluginKit change for 0.68.0 as additive: one interface diff, PluginTriggerInfo gaining fields on a non-frozen struct with its old init preserved as @_disfavoredOverload. No symbol was removed, and currentPluginKitVersion is unchanged at 19.

Why it surfaced now

The step arrived in #2361 on 2026-08-21. The plugin tags pushed today are the first plugin releases since, so this is its first execution.

Fix

build-plugin.sh builds the plugin and its dependencies into one flat CONFIGURATION_BUILD_DIR (build/Plugins/$arch), so the framework is already on disk next to the built bundle. Copy it beside the unzipped bundle before probing.

Putting it in the work directory rather than passing build/Plugins/$ARCH as a second search directory is deliberate: the script both searches and scans each directory it is given, so passing the build dir makes it find and dlopen the same bundle twice and report "All 2 plugins load".

Verified locally

Built BeancountDriver into a flat products dir, copied the bundle alone into a temp dir to imitate the zip, and ran the script both ways:

$ verify-plugin-loads.sh "$W"              # bundle alone, as CI does today
1 of 1 plugins will not load: BeancountDriver

$ verify-plugin-loads.sh "$W2"             # framework copied beside it, as this PR does
  ✓ BeancountDriver
All 1 plugins load.

The first command reproduces the CI failure exactly; the second is this change.

After merging

The 12 tags are already pushed, so they need re-running rather than re-tagging. workflow_dispatch runs the workflow from the default branch, so a single dispatch with all 12 tag values picks this up:

plugin-beancount-v1.0.5,plugin-bigquery-v1.0.25,plugin-cassandra-v1.0.33,plugin-cloudflare-d1-v1.0.35,plugin-dameng-v1.0.3,plugin-duckdb-v1.0.35,plugin-libsql-v1.0.23,plugin-mssql-v1.0.38,plugin-oracle-v1.2.22,plugin-snowflake-v1.0.4,plugin-teradata-v1.0.4,plugin-trino-v1.0.5

No plugin was published by the failed runs: the load check runs before the release and registry steps.

https://claude.ai/code/session_01DBDRXfDuGrLJV2HrM2d4M4

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.