test(ui): fix timing flake in SettingsPage Dynamic Tools tests

[itomek]

Fixes #1933.

The Agent UI Vitest job could fail on unrelated PRs: SettingsPage.test.tsx > is disabled and reflects the env value when locked flaked on CI (Dependabot #1802 run 28763820070 and #1803) while passing on identical code elsewhere, eroding trust in a red check. The tests waited for the toggle to exist, but it renders from first paint (unchecked, disabled until settings load), so assertions and clicks raced the async getSettings() flush — clicks on the still-disabled toggle silently no-op. Five of the seven tests carried the race; CI load determined whether it fired. After: the tests wait for the settled state (toggle enabled, or the lock note for the locked case), and the API mocks resolve one macrotask later — like real HTTP — so the race stays permanently exposed instead of masked. (No env-var or cross-file state leakage was involved; the "env value" in the test name is the GAIA_DYNAMIC_TOOLS lock note rendered by the UI.)

Proof

Race reproduced deterministically on unfixed code by giving the mocks a realistic 30 ms response latency (kept in this PR as the regression guard) — including the exact assertion that failed in CI:

❯ src/components/__tests__/SettingsPage.test.tsx (7 tests | 5 failed)
   × renders the loaded value (off by default)
   × toggles when the visible row/label is clicked, not just the hidden input
   × is disabled and reflects the env value when locked
   × guards against a double-click while a save is in flight (single PUT)
   × reverts and surfaces an error when the save fails (no silent fallback)

With the fix, stable under shuffle and repetition (run in src/gaia/apps/webui):

$ for seed in 1 42 777 20260706 999983; do npx vitest run --sequence.shuffle --sequence.seed=$seed; done
seed=1         Tests  109 passed (109)
seed=42        Tests  109 passed (109)
seed=777       Tests  109 passed (109)
seed=20260706  Tests  109 passed (109)
seed=999983    Tests  109 passed (109)

15 consecutive runs of the file: 0 failures. npx tsc --noEmit clean. Also fixed: getSystemStatus was mocked as null, throwing a TypeError inside the component in every test's stderr; it now returns a valid SystemStatus.

Test plan

• cd src/gaia/apps/webui && npx vitest run — 109/109 pass
• npx vitest run --sequence.shuffle (any seed) — 109/109 pass
• Vitest CI job green on this PR

[itomek]

CI evidence: the full "Test Electron Framework and Apps" workflow — including the "Test Agent UI Components (Vitest)" job this PR fixes — is green on this branch: run 28820012621 (manually dispatched after updating the branch from main).

🔍 Why a manual dispatch, and history of the earlier red run

• The workflow's PR path filter (src/gaia/apps/*/webui/**) never matches the Agent UI at src/gaia/apps/webui/**, so this PR gets no Vitest check on its own — tracked in CI: Agent UI Vitest suite never runs on Agent UI changes (path filter misses src/gaia/apps/webui) #1934. A workflow_dispatch on the branch is the only way to run it here.
• An earlier dispatch (run 28812081199) had the Vitest job green but the unrelated "Test Electron Framework" job red — that was the stale <title>GAIA</title> assertion fixed on main by fix(tests): match chat-app title assertion to renamed Agent UI title #1927; after updating the branch, everything passes.
• Main itself reproduced the flake this PR fixes: run 28810778335 (a push run on main) failed on exactly is disabled and reflects the env value when locked.

[github-actions]

Verdict: Approve

This is a clean, test-only fix for a real CI flake (#1933) in the SettingsPage Dynamic Tools tests. The old tests waited for the toggle merely to exist — but it renders from first paint (disabled until getSettings() resolves), so assertions and clicks raced the async load and clicks on the still-disabled toggle silently no-op'd. The fix waits for the settled state instead (toggle enabled, or the lock note for the locked case) and gives the API mocks realistic one-macrotask latency so the race stays permanently exposed rather than masked. No blocking issues; production code is untouched.

The root-cause writeup and the deterministic 30 ms repro (kept in-tree as the regression guard) are exactly what a flake fix should carry, and it also quietly fixes the getSystemStatus mock that was throwing a TypeError in every test's stderr.

🔍 Technical details

Verified against the component:

• SettingsPage.tsx:485 — disabled={!settingsLoaded || savingDynamicTools || dynamicToolsLocked} confirms the new findLoadedDynamicToolsToggle() helper (not.toBeDisabled()) is a correct proxy for "settings landed" in the unlocked/not-saving path.
• The locked test correctly can't use that helper (the toggle stays disabled when locked) and instead awaits screen.findByText(/GAIA_DYNAMIC_TOOLS/), which only renders after settings load — right call.
• makeSystemStatus() supplies every required field of SystemStatus (types/index.ts:400); the remaining fields (init_state, init_tasks, detected_devices) are optional, consistent with the PR's "tsc --noEmit clean" claim.

Strengths:

• 🟢 Fixes the actual mechanism, not the symptom — waiting on settled UI state rather than adding sleeps/retries, and keeping the injected latency as a standing regression guard so the race can't silently return.
• 🟢 Incidental correctness win: replacing the null as never getSystemStatus mock with a valid object removes a TypeError that was firing in every test.
• 🟢 Scope-clean and well-evidenced (shuffle across five seeds + 15 repeat runs).

No issues found.

[itomek]

Live real-surface verification of the behavior the flaky test asserts — real Agent UI (built frontend + gaia.ui.server) started with GAIA_DYNAMIC_TOOLS=1:

• GET /api/settings → {"custom_model":null,"model_status":null,"context_size":null,"agent_mode":"autonomous","dynamic_tools":true,"dynamic_tools_locked":true}
• Settings page renders the Dynamic Tools toggle on and disabled, with the lock note: "Controlled by GAIA_DYNAMIC_TOOLS — unset that environment variable to change this here."
• Clicking the toggle/label while locked changes nothing and issues no PUT /api/settings (network log shows only GETs) — the exact no-op the test suite relies on.

Tested by driving the served UI in a headless browser against the locked backend; screenshot captured in-session.