test(desktop): click a mounted rail in the retry-while-filtered story

[liugddx]

Summary

This fixes the last open item of #5995: the Storybook story product-workhub--retry-while-work-filtered intermittently never shows the work filter.

Root cause. The play function sends a message, waits for the first-attempt failure alert, and then clicks canvasElement.querySelector('.workhub-message-rail'), which is the first rail in the DOM. The send follows the latest Turn (followLatest), and ChatView's virtua virtualizer (packages/ui/src/chat-view.tsx:959) unmounts Turns that scroll out. It keeps only Turns that hold focus or a selection endpoint (:1155); hover doesn't count. When the alert lands before that scroll has settled, the first rail is still Turn 1's, and it can detach between user-event's hover and press. The pointerdown and click then go to a node outside the document. React never sees them and user-event raises no error, so the filter never appears, and waitFor times out on "显示全部对话". In the common case Turn 1 has already been unmounted, the first rail belongs to Turn 2, and the story passes. This is a race in the test only; the product behaves correctly.

Fix. Click the newest linked Turn's rail, which stays mounted while the transcript follows the latest Turn. The other WorkHub stories click rails only before any send, so they don't share the race.

Fixes #5995 (items 1 and 2 already landed in #6008 and #6007).

Verification

I reproduced and verified this on Linux CI in a temporary fork workflow (ubuntu-24.04, Node 24, Chromium headless shell). The workflow ran this story through the CI smoke's own smokeStory(), two copies in parallel with two other WorkHub stories as load, with page instrumentation (rail pointer/mouse events, filter and alert mutations):

	runs	failures
main, 4-way load (run 37868451921)	120	50
main, alone	40	0
main, instrumented (run 37870979040)	50	18: 17 hovered Turn 1's payments rail and never received pointerdown; the other never received the hover
this fix, 4-way load (run 37873036640)	120	0

In every failing timeline, the rails left in the DOM at the failure were Turn 2's and Turn 3's; Turn 1's had been unmounted. Passing timelines clicked Turn 2's release rail. I also ruled out the WorkHub reveal animation's pointer-events: none gate: it never runs in Storybook, and the history's pointer-events stayed auto throughout.

Not yours: under the same 4-way load, product-workhub--usage-inspector also fails sometimes (toBeVisible). The smoke's existing alone-retry absorbs it ("passed alone; not a failure"), and this PR does not address it.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code built the instrumented CI repro, identified the root cause and wrote the one-line fix. I reviewed the evidence and the change.

Checklist

• Tests cover the change and fail without it. Under 4-way load, the story fails 50/120 without this change and 0/120 with it.
• Lint, format, typecheck and the affected suites pass locally. Biome lint passes on the story, and the story was verified in the CI repro above.

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

🤖 Generated with Claude Code