FEAT GUI: Add dataset loading controls and access guidance #2756

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

Available built-in datasets need a clear loading workflow. Users must understand why a gated dataset cannot load and how to configure access without entering secrets into a new GUI credential store.

Work item 11 of 17 in #2744. Technical prerequisites: items 9-10. Keep not ready yet until promoted.

Describe the solution you'd like

Extend the existing Datasets cards/detail views with explorer-specific Load/status/access guidance and supported provider options. Reuse the metadata and operation adapter from #2754/#2753, the current shared API/error layer, and the Scenario form's existing loading/status patterns. Do not add another dataset picker, catalog, or credential store.

• Show source/license information and known credential/gated-access prerequisites. Link to external access instructions or the existing configuration surface where permitted. Do not automatically accept dataset terms.
• State that loading uses backend credentials and adds data to shared deployment memory. Do not add token fields, display stored tokens, or imply per-user private datasets.
• Show pending/loading/persisting/success/failure states from the operation API; prevent duplicate submissions and allow safe status recovery while navigating.
• Explain missing configuration, access denial, offline/upstream errors, invalid options, partial loading, and lost operation status distinctly. Retry must follow the service's semantics.
• Refresh loaded counts and table availability after success without losing browse filters or return-to-chat context.

Acceptance criteria:

• Public and gated provider flows work against mocked/local providers without privileged access.
• A user must explicitly choose Load; viewing a card does not download anything.
• Configured credentials are never treated as guaranteed gated access.
• Loading options, duplicate-click protection, errors, retry, and successful refresh are covered by component tests.
• The UI remains accessible and responsive during a long load and no target is required just to load/browse a dataset.

Describe alternatives you've considered, if relevant

Do not introduce per-user authentication to dataset providers, a password/token manager, background prefetch of all datasets, or unsupported cancellation/resume promises.

Additional context

Build on the Datasets section and shared API/error layer from earlier items. Reuse existing configuration-access checks and Fluent UI form/status patterns. Follow frontend style/test instructions. This completes the built-in provider milestone.

Relationship to scenario dataset generation

The scenario dataset plan supports dynamic generation during preparation, with stored-data reuse. #3143's named-source, limit, and fetch-policy controls are merged. Main already includes ScenarioDatasetTable, useScenarioDatasets, and the scenario-scoped explicit Load API. Reuse their shared metadata/status/error patterns, but do not mistake that missing-only Scenario action for the explorer's known-provider operation/status/access workflow in #2753 and this issue.

A built-in dataset Load is distinct from a future model-driven Generate action. Keep ordinary loading/browsing usable without choosing a model target, and retain backend-only credentials and explicit submission. Already-stored generated objectives are browsable without generation; their origin is not proof of a registered provider or permission to regenerate them.

Explicit scenario refresh is also shipped in #3206. Do not rebuild it or silently substitute always refresh for an ordinary provider Load/retry. New generator target/instructions/count controls or additional destructive-refresh UX are separate follow-ups. Do not trigger generation by viewing a card, changing filters, or opening configuration. This October 31, 2026 scope refresh changes no prerequisites or promotion order.