Flaky test: pairing queue focus assertion is not wrapped in waitFor #694

src/App.test.tsx → "handles simultaneous pairing requests without discarding the queue" fails intermittently on CI (Linux, full suite in parallel) while passing consistently locally.

Observed on the CI run for #693, a two-file diff touching only src/settings/, which cannot affect this test:

FAIL src/App.test.tsx > Switchify PC shell > handles simultaneous pairing requests without discarding the queue
Error: expect(element).toHaveFocus()

The same test passed 10/10 locally in isolation on main.

Cause

The final assertion is not wrapped in waitFor:

await waitFor(() => expect(screen.queryByRole("heading", { name: "Galaxy" })).not.toBeInTheDocument());
expect(approve).toHaveBeenCalledWith("pair-2");
expect(screen.getByRole("heading", { name: "Pixel" })).toBeInTheDocument();
expect(screen.getByRole("button", { name: "Reject pairing request from Pixel, code 111111" })).toHaveFocus();

Focus is moved by an effect in PairingDialog (src/App.tsx, the dialogRef.current?.querySelector<HTMLButtonElement>("button:not(:disabled)")?.focus() effect). The preceding waitFor only guarantees the removed heading is gone — it does not guarantee the focus effect for the re-rendered dialog has run. Under CI load the assertion can observe the intermediate state.

Note the earlier focus assertion in the same test is correctly wrapped:

await waitFor(() => expect(dialog).toHaveFocus());

Fix

Wrap the final focus assertion in waitFor to match. Worth a scan for the same unwrapped-toHaveFocus pattern elsewhere in the suite.

This is a test-only defect; the application focus behavior itself is correct.