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

Add explicit Load controls to available-provider cards/detail views and show the provider's supported variant/options before submission.

• 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 scenario preparation, with stored-data reuse. The still-open #3143 adds the scenario form's named-source, limit, and fetch-policy controls. Reuse its shared metadata and form pieces where they fit, but do not mistake that scenario table for the explorer's explicit Load/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.

A generator target/instructions/count form and destructive refresh warnings belong to separately approved follow-ups. Do not add those controls here or trigger generation by viewing a provider card, changing filters, or opening scenario configuration. This does not change the existing prerequisites or promotion order.