FEAT GUI: Load built-in datasets into memory on request

Start with the dataset backend service, SeedDatasetProvider, existing memory dataset insertion APIs, and current backend asynchronous operation and error conventions. First verify that item 9's provider identity and supported-option contract has been promoted. Done means tested public and gated fake providers load through the existing path, expose honest operation status, avoid duplicate work, preserve failure semantics, and make results queryable through the explorer APIs.

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

Users need an explicit way to load a built-in dataset from the explorer. Some loads are long-running, gated, or asset-heavy, and a failed/repeated request must not misrepresent the dataset as fully loaded or create duplicates.

Work item 10 of 17 in #2744. Technical prerequisite: item 9's registered provider identity and supported-option contract. Keep not ready yet until promoted.

Describe the solution you'd like

Add a service operation to load a registered provider into existing CentralMemory using backend-configured credentials and existing provider/persistence APIs.

• Accept only a known provider and its supported, validated non-secret options. Do not accept arbitrary URLs, modules, code, or credential values.
• Expose a load-operation identifier and status so the GUI can handle long-running work without blocking navigation or the API event loop. Reuse existing runtime/service patterns instead of building a durable job platform.
• Report useful stages such as loading and persisting rather than invented percentage progress. Define terminal success/failure, partial-load reporting, and honest behavior if process-local status is lost after restart.
• Prevent duplicate simultaneous submissions for the same provider/options. Define retry/already-loaded behavior using existing persistence/deduplication behavior; do not silently overwrite user data or reload a different variant under the same identity.
• Respect application authorization, use the configured server credentials, and make shared-memory scope explicit. Distinguish missing credentials, gated-access denial, invalid options, upstream/network failure, and persistence failure without leaking secrets.

Acceptance criteria:

• Public and gated mock providers load through the existing provider-to-memory path.
• Browsing/GET requests never trigger this operation.
• Concurrent duplicate requests and retries have documented, tested behavior.
• Failure after partial work is not reported as complete success.
• Loaded summaries/rows become queryable through the existing explorer APIs.
• Tests use fake providers/local media and cover status, failures, authorization, and invalid requests without network datasets or keys.

Describe alternatives you've considered, if relevant

No new memory tables/migrations, separate dataset store, browser credential handling, arbitrary loader execution, or mandatory durable queue. Do not promise resumable/cancellable provider downloads unless the provider actually supports them.

Additional context

Start with the dataset backend service, SeedDatasetProvider, existing memory dataset insertion APIs, and current backend asynchronous operation/error conventions. Keep blocking third-party work off async request paths and follow Python/dataset/database/test instructions.