feat(registry): add dataProvider.enabled config option

[ricardo-devis-agullo]

What

Adds a dataProvider namespace to the registry configuration with an enabled flag (default true):

oc.Registry({
  baseUrl: 'https://components.mycompany.com/',
  dataProvider: { enabled: false }
});

When enabled is false, the registry never fetches nor runs a component's server.js, even if one exists in the storage. Every component is served through the same path already used by components that ship no data provider: the request parameters are passed straight through as the view model, with _staticPath, _baseUrl, _componentName and _componentVersion appended.

Why namespaced rather than a flat boolean

Two related features are planned: a global fallback handler (logic injected for components that have no data provider, or when they're all disabled) and middleware wrapping whichever provider ends up running. Nesting now means those land as dataProvider.fallback and dataProvider.middleware without a deprecation cycle — the sanitiser already carries shims for s3 and discovery and this avoids adding a third.

server was deliberately avoided as a name: it is already taken by the HTTP server adapter config (server: { adapter, options }). dataProvider is also the term the codebase already uses (component.oc.files.dataProvider).

Changes

• src/types.ts — dataProvider: { enabled: boolean } on Config.
• src/registry/domain/options-sanitiser.ts — RegistryOptions overrides it with an all-optional form (same pattern as discovery); default applied by spreading the user object so future keys survive.
• src/registry/domain/validators/registry-configuration.ts — signature accepts the pre-sanitised shape.
• src/registry/routes/helpers/get-component.ts — the existing "no data provider" branch now also triggers when the option is off.

The check is conf.dataProvider?.enabled === false rather than !conf.dataProvider?.enabled, because an absent dataProvider must continue to mean enabled for any config object built without going through the sanitiser.

Behaviour note

The props-only path emits data = { component: { props: {...} } }, not bare props. That is pre-existing behaviour for components without a server.js, but it does mean a view written against a server.js model sees a different shape once the option is flipped on an existing registry.

Tests

• registry-domain-options-sanitiser — default is { enabled: true }; explicit false is preserved; a partial object is filled in.
• registry-routes-component — a component that does declare a server.js returns 200, never calls repository.getDataProvider, and yields the request parameters as the model.

961 unit tests passing, lint and typecheck clean.