perf: faster plugin config-schema fetch + UI skeleton loader

[albanm]

Speed up the processing edit page when the plugin config schema is loaded.

• Bump @data-fair/lib-node-registry to ^0.6.0 (api + worker). 0.6 reworks the cache check into a single conditional GET /:id/download with If-Modified-Since: warm caches return 304 (no body), misses stream the tarball in one round trip instead of two.
• Pin the registry compose service to ghcr.io/data-fair/registry:main so dev runs against the image that serves the new download semantics (Last-Modified + X-Artefact-* headers + 304).
• Refactor pages/processings/[id]/index.vue to drive the plugin metadata and config-schema fetches through useFetch from @data-fair/lib-vue. Both fire in parallel as soon as the processing loads, and a v-skeleton-loader renders in place of the vjsf form while they're pending.

Why: opening a processing felt slow because the API made a round trip to the registry on every visit even when the local plugin cache was warm, and the UI showed a blank gap during that time.

Regression risks:

• 0.5 → 0.6 changes the request pattern (now hits /download with If-Modified-Since instead of /:id + /tarball). Non-dev deployments need a registry image that serves the new headers — older registries won't return version/hasNativeModules and the worker will get empty strings/false for those fields.
• Both useFetch calls pass notifError: false, so non-404/403 errors (e.g. a 500 from the registry or schema endpoint) are silenced into error.value and the form just doesn't render — no banner, no notification. Previously those propagated as thrown exceptions.
• The artefact fetch on this page no longer goes through the shared usePluginFetch singleton; repeat visits to processings using the same plugin won't hit the in-memory cache.