Flaky tests: ViewHeader connect/disconnect animation + TUI OAuth step-up #1699

Two intermittently-failing tests observed during work on #1626 (PR #1697). Both pass on re-run; both are timing-sensitive assertions rather than product bugs. Tracking them so they can be stabilized.

1. ViewHeader.test.tsx — "animates the server name and disconnect controls in on connect, out on disconnect (#1450)"

File: clients/web/src/components/groups/ViewHeader/ViewHeader.test.tsx (~line 351–356)

Symptom (seen in CI on the build job):

Error: expect(element).not.toBeInTheDocument()
expected document not to contain element, found <button …>

Root cause: the test await waitFor(...)s that the server-name text is removed after its exit Transition, then does a synchronous queryByRole("button", { name: "Disconnect from server" }) assertion. The server name and the Disconnect button are removed by two independent Mantine Transition exits; on a slow runner the button's exit can lag the name's, so it's still in the DOM at the synchronous check.

Suggested fix: wrap the Disconnect-button "removed" assertion in its own waitFor (like the server-name one), so it doesn't assume the two transitions complete in lockstep.

2. TUI App.test.tsx — "App (OAuth result branches) > completes a standard step-up authorize when OAuth succeeds"

File: clients/tui/__tests__/App.test.tsx

Symptom (seen locally under coverage:tui, i.e. v8-instrumented / slower):

AssertionError: expected '────…' to contain 'Step-up authorization succeeded'

Passed on a plain validate:tui run and on re-run. The assertion reads the Ink frame before the success line has rendered under the slower instrumented run.

Suggested fix: poll/waitFor the Ink lastFrame() for the expected line instead of asserting a single snapshot, or advance timers deterministically.

Notes

• Neither is related to the era-aware connection work; flagged from Era-aware connection model & capability gating (#1626) #1697.
• There is currently no retry configured in any vitest project, so a flake fails the whole CI build job. Consider whether a small retry: 1 on the affected projects is warranted in addition to fixing the assertions (or keep zero-retry and just fix the timing assertions).