FEAT GUI: Describe available built-in dataset providers #2754

Is your feature request related to a problem? Please describe.

The standalone explorer needs useful descriptions of unloaded built-in providers. Provider names, availability, stored origins and counts are already in the catalog.

Part of #2744. Technical prerequisites: completed #2746/#2747. On November 4, 2026, the maintainer explicitly promoted this issue in parallel with #2752; inspiration is not a dependency. This issue is available for a contributor to claim. Check the live assignee and claim thread before starting. #2757 has also been separately promoted for parallel work. Later work, including #2753, remains gated until separately promoted.

Describe the solution you'd like

Extend the existing catalog and cards/details with missing provider descriptors and In memory/Available views. Preserve opaque keys, count semantics, routes and browse state. Do not create another catalog/registry.

The first version describes each supported built-in provider's default configuration. Expose known description, source/license/access links, modalities/harm categories and coarse size/load-time hints separately from exact stored counts/origins. Unknown facts remain unknown. Unsupported metadata on one provider must not break stored-data browsing or the rest of the catalog.

Enumeration must not download providers, invoke models or materialize seeds. Reuse trusted provider metadata/descriptors; do not contact gated sources to test access. Known required environment-variable names may be shown, never credential values. Configuration is not proof of permission.

Acceptance criteria:

• Stored, available-to-load and combined views share catalog/detail routes; unloaded cards explain the provider rather than report a missing loaded dataset.
• Provider descriptions/estimates/availability remain distinct from stored counts/provenance; unknown and unlabeled semantics stay correct.
• Default public/gated providers can be described using local/fake fixtures without credentials or remote fetches.
• Missing metadata or unsupported loading does not fail the entire catalog and is explained clearly.
• Existing clients remain compatible; metadata/read-only and component tests cover both loaded and unloaded views.

Describe alternatives you've considered, if relevant

No generic constructor/options form, arbitrary kwargs, variant selector, second registry or Load operation. General variants wait for an explicit stored-identity/coexistence design.

Additional context

Start with SeedDatasetProvider, SeedDatasetMetadata, DatasetService, dataset models, useLoadedDatasets, DatasetCard and DatasetSelection. Shared provider metadata owns facts; backend projects them and GUI displays them.

VLGuard subsets all currently use vlguard, while missing-only preparation checks stored names. Name presence cannot prove another variant is loaded. Default-only support avoids silently mixing populations or inventing memory identity.

Reuse #3143 metadata/source controls and #2956/#3116 preparation. Generated configurations are not automatic unloaded built-in cards. #2753 supplies loading, #2756 its UI. Scope narrowed November 4, 2026 against main c756e7f8f2b8e24987907ec4691ec0c54a0b0677.