fix: clearer plugin 404 / access errors at the registry boundary

[albanm]

Turns opaque 500s from the registry boundary into actionable 403/404 responses, and lets a superadmin still create a processing for an owner who has no plugin access (it lands in the existing broken-plugin state instead of failing the POST).

What changed:

• ensurePluginAndReadSchema now translates registry errors at the boundary (lib-express/error-handler was collapsing every AxiosRequestError to 500): 403 → Le compte X n'a pas accès au plugin Y., 404 → Le plugin Y est introuvable dans le registre., anything else → 502.
• prepareProcessing short-circuits when the processing has no config — there's nothing to prepare, and skipping the registry fetch lets a no-config / inactive processing be created even when the owner lacks plugin access. Same broken-state UX the UI already handles for deleted plugins via the pluginBroken banner.
• GET /:id/plugin-config-schema now returns a descriptive 404 body instead of empty when the plugin ships no schema (covers v5 legacy plugins where the schema lives in plugin.json#processingConfigSchema, now read as a fallback).
• UI: a watch on configSchemaFetch.error surfaces non-404 fetch errors as a toast (configSchemaFetchError / Échec du chargement du schéma de configuration du plugin).

Why: a superadmin can list every registry artefact regardless of privateAccess, so the create-processing wizard let them pick a plugin and pair it with an owner that had no access — and the POST then 500'd with no actionable message. Pairs with registry 38217ee (0.5.1), which makes the /:id/download route return 403 instead of 404 when the caller's account isn't on privateAccess, so the owner name surfaces in the processings-side message.

Regression risks:

• prepareProcessing is no longer called on bare create (config absent). Any plugin whose prepare() had side effects independent of the config would silently stop running until the first config-bearing PATCH. The known plugins all key off the config, but worth a sanity check against your plugin set.
• POST/PATCH now return 403/404/502 where they used to return 500 for registry failures. Any caller / dashboard / alert keying off 500 will shift — the worker is already explicit about 403/404 so it's unaffected.
• The catch-all 502 swallows the underlying axios message in the response body. The original is still logged via internalError (5xx branch), but ops will lean on logs rather than the body when the registry itself is broken.
• The UI configSchemaFetchError toast now fires whenever an admin opens a processing whose owner lacks plugin access. Probably what you want — flagging anyway.