Gatsby v5 plugin apiVersion requirement: which compatibility signal should gate a deployment?

After moving a site from Gatsby v4 to v5, the plugin ecosystem changed: plugins are expected to declare a supported apiVersion, and plugins written against the older API can fail during gatsby build or, worse, behave silently differently in a deployed build.

The uncertainty is how to treat this boundary operationally. Build logs from the hosting provider tend to surface generic failures (module resolution errors, hook errors in gatsby-node or SSR APIs) that do not clearly identify an incompatible plugin as the root cause. At the same time, a plugin missing an apiVersion declaration is not necessarily broken, so a strict audit may flag plugins that work fine.

Assuming Gatsby v5 with a mixed set of official and community plugins, and a CI pipeline that deploys on a successful production build:

• Is there a documented, reliable way to make an incompatible plugin fail fast and identifiably in build logs, rather than as a generic error?
• Should the absence of a declared apiVersion in a plugin be treated as a deployment blocker, or only as a warning?
• Is a local production build on the same Node version considered sufficient verification of plugin compatibility before deploying?