[GUI] Keep saved initializer settings visible when catalog loading fails

[romanlutz]

Important

Maintainer-owned: This issue is intentionally labeled not ready yet. Please leave implementation to a PyRIT maintainer unless a maintainer explicitly assigns or approves the work.

Describe the bug

A failure from the initializer catalog endpoint (GET /api/initializers) causes the page to report both Baseline initializers and Additional initializers as empty, even when GET /api/initializers/settings succeeds and returns valid saved settings.

This presents a transient catalog outage as a configuration state change. A user can no longer inspect the initializers that are actually configured and may conclude that startup or saved configuration was lost. Severity: moderate because the UI gives a materially false account of persisted state until recovery.

Steps/Code to Reproduce

1. Configure one baseline initializer and one additional refresh_datasets initializer with days set to 14.
2. Open the Initializers page and confirm both cards are visible.
3. Make GET /api/initializers return HTTP 503 with a synthetic catalog error while allowing GET /api/initializers/settings to return the valid settings.
4. Choose Refresh.
5. Observe the catalog error alert and the two empty-state messages: No baseline initializers are configured and No additional initializers are configured.
6. Restore the catalog response and choose Refresh again.
7. Observe that the same baseline and additional settings reappear without being recreated.

# N/A - GUI-only reproduction; no Python code is required.

Expected Results

The page should distinguish catalog availability from saved configuration. It should continue rendering settings returned by the settings endpoint, or preserve the last known settings with a clear stale/error state, rather than claiming that both sections are empty.

Actual Results

One catalog request failure clears both rendered sections and replaces valid settings with false empty-state messages. The add controls are also unavailable. A subsequent successful refresh restores the unchanged settings, demonstrating that no configuration was actually removed. The reproduction used only a synthetic local HTTP 503 response.

Screenshots

Sanitized before/recovery screenshots and WebM evidence, showing only the application viewport and synthetic values/errors, are attached in the evidence comment below.

Versions

• PyRIT commit: 3dd9946ee4ef08a2048c64ff4b29d3a856a8068e
• OS: Windows_NT
• Browser automation: Playwright Chromium (@playwright/test 1.62.0)
• pyrit.show_versions(): N/A for this frontend-only reproduction

[github-actions]

Thanks for the bug report! A maintainer will triage shortly. If you can add a minimal reproduction, screenshots, or your PyRIT/OS version (you can edit this issue), that would help us investigate.

[romanlutz]

Sanitized evidence

During the catalog-only failure — the page receives and displays the synthetic catalog error, then incorrectly reports both configured sections as empty.

After the catalog recovers — a normal refresh restores the unchanged baseline and additional settings without recreating either one.

Watch the focused 6-second WebM reproduction

Safety: recorded against local in-memory services with a synthetic HTTP 503 and numeric sample value only. No credentials, provider data, browser chrome, filesystem paths, or backend traceback are present.