BUG Configuration keeps runtime-status errors after polling recovers

从 frontend/src/components/Configuration/Reinitialize.tsx 开始，重点查看第 36-50 行的刷新处理以及第 82 行的错误渲染。运行 issue 中描述的聚焦 Playwright 探针，然后验证恢复后的状态轮询只会移除过时的轮询错误，同时保留应用错误和确实需要重启的状态。

Describe the bug

A single failed runtime-status request leaves a red error in Configuration even after subsequent polls succeed and report a healthy, ready runtime. Reload file does not clear it. Navigating away from Configuration and returning does.

This is a stale status-request error, not a failed reinitialization or a real restart-required state. The administrator sees a failure message after the condition that produced it has recovered.

Severity: P2 / Medium. The misleading status makes it difficult to tell whether the runtime still needs attention. Observed in the Configuration UI added by #2833; reproducing it does not require applying configuration or calling an external provider.

Steps/Code to Reproduce

1. Open Configuration on a local instance and wait for a successful GET /api/config/runtime poll.
2. Make exactly one subsequent status request return HTTP 503 with a recognizable detail message, then allow requests through normally.
3. Wait for at least three more successful status polls. Confirm their responses report state: ready and outcome: success.
4. Observe that the earlier error remains visible.
5. Click Reload file. The error still remains.
6. Navigate to Home and back to Configuration. The error disappears.

The failure needs to be injected after the component is mounted, rather than racing its initial request. A minimal Playwright probe, with page and expect from @playwright/test and baseURL set to the running local frontend, is:

let failNextPoll = false;
let successfulPolls = 0;
const detail = 'Runtime status temporarily unavailable.';

await page.addInitScript(() => {
  localStorage.setItem('pyrit-tour-completed', 'true');
});
await page.route('**/api/config/runtime', async route => {
  if (failNextPoll) {
    failNextPoll = false;
    await route.fulfill({ status: 503, json: { detail } });
    return;
  }
  const response = await route.fetch();
  if (response.ok()) successfulPolls += 1;
  await route.fulfill({ response });
});

await page.goto('/config');
await expect.poll(() => successfulPolls, { timeout: 15000 })
  .toBeGreaterThanOrEqual(1);
const beforeFailure = successfulPolls;
failNextPoll = true;
const error = page.getByText(detail, { exact: true });
await expect(error).toBeVisible();
await expect.poll(() => successfulPolls, { timeout: 15000 })
  .toBeGreaterThanOrEqual(beforeFailure + 3);

// Fails on the tested commit: recovered polling leaves the old error visible.
await expect(error).not.toBeVisible();

Expected Results

Clear a status-poll error after status polling recovers. Do not clear an unrelated apply error or hide a real restart-required state. These error sources should be distinguishable in state and in regression tests.

Actual Results

The focused audit recorded eight successful polls overall, including at least three after the injected failure. The latest response was:

{
  "state": "ready",
  "outcome": "success",
  "message": "PyRIT is ready.",
  "enabled": true,
  "applying": false
}

The failure message remained both after those successful polls and after Reload file. Leaving and returning to Configuration cleared it.

In Reinitialize.tsx, lines 36-50, refresh success updates status, while refresh failure sets error. A successful refresh does not clear the recovered polling error, which remains rendered at line 82.

Workaround: Navigate away and back, or fully reload the page. Reinitializing a healthy runtime should not be necessary to clear a recovered status-request failure.

Screenshots

Captured in the September 25 catch-up audit artifacts, not uploaded to this issue:

• daily-2026-09-25-catchup/manual/runtime-stale-status-error.png
• Poll counts, latest response, and recovery observations: daily-2026-09-25-catchup/manual/runtime-status-recovery-ux.json

The relevant observations and reproduction code are included above so the artifact files are not required.

Versions

• OS: Windows, x86-64.
• Browser: Chromium through Playwright; focused reproduction at 1280 x 800.
• Python: CPython 3.14.4, uv-managed environment.
• PyRIT: 1.2.0.dev0, editable source checkout at c32546a1e3d069ea9794df31ded86e17487dcf2a.
• Local-only backend. The probe injected one failed status read and allowed subsequent requests to reach the real backend. No live external provider was used.
• Full pyrit.show_versions() output was not captured.