Chat can return to the first message instead of the tail when switching back to a populated session

Summary

A new fixture-backed real-application smoke test intermittently catches a session-return scrolling failure in the production-shaped Release app. After selecting a 240-message session A, selecting session B, and returning to A, the selected conversation is correct but the viewport remains at messages 1-3 instead of the final message.

The screenshot confirms the failed visibility assertion. The exact cause is not established: investigate application scroll/lifecycle behavior and possible UI Automation timing effects before changing production code. Do not weaken the assertion or add a blind retry to obtain a green run.

Related: #1424 (Track WinUI ItemsView fix and retire Reactor preview.12 Markdown workaround) and #1426 (fix(chat): avoid session-switch crashes without clipping Markdown lists).

Reproduction

The new harness currently lives in the local feature/gateway-fixture-harness working tree and has not been published yet. Its files and proof are being handed to the fix agent separately. It launches the real application against an authenticated loopback WebSocket Gateway with synthetic data, not a mock chat provider. No real Gateway, WSL installation, provider, or AI call is required.

1. Build an unpackaged Release app with DevBuild=false.
2. Run scripts\test-gateway-fixture.ps1 -AppPath '<current Release OpenClaw.Tray.WinUI.exe>' -Configuration Release -Screenshots.
3. In GatewayFixtureUiTests.SessionPickerSwitchesRealHistoriesAndShowsMessage240AtBothWidths, select Fixture: 240-message conversation through the actual composer session-picker flyout.
4. Verify its final line, FIXTURE LONG END 240, is naturally visible before issuing any manual scroll command.
5. Select Fixture: research conversation, verify that conversation's content, then select the long session again.
6. On the failing repeat, the long conversation stays at its beginning for the 20-second visibility deadline.

Expected behavior

Returning to the long conversation after it was at the tail should show the actual final message, without requiring a manual scroll repair. Session identity, transcript content, and the user's intended scroll position must remain coherent. Preserve row-targeted navigation and virtualization; checking only the current scroll extent is insufficient.

Observed evidence

• Screenshot shows the connected app, the long session selected, and FIXTURE LONG BEGIN: message 001. followed by messages 002 and 003. The final marker is not visible.
• Gateway trace reports successful handshake, session/model/supporting reads, and successful chat.history for agent:main:main, agent:main:fixture-long, and agent:research:fixture-other. There are no unsupported requests in this run. The return to the long conversation uses already loaded history.
• Latest Release smoke: 22/22 profile/app tests passed; 3/4 native UI tests passed; this natural-tail test failed. Earlier Release runs passed, so the failure is intermittent and earlier successes must not replace the failed result.
• Latest Debug smoke passed 26/26. An earlier Debug run also became unresponsive while inspecting the long transcript; its cause is unconfirmed and may be separate. The harness now bounds UI tests and cleans up owned processes even when a synchronous UI Automation call stalls.
• Required repository build, Shared tests (4,034 passed, 32 skipped), Tray tests (3,006 passed), and WinNode CLI tests (127 passed) passed.

Environment: Windows x64, .NET runtime 10.0.12, Windows App SDK 2.4.0, Reactor preview.12. The failing Release runtime configuration has System.Diagnostics.Debugger.IsSupported=false and no attached debugger.

Proof bundle identifiers for the coordinating maintainer/agent:

• Failing run: 3270bac7f7854ca8a2737baec345be85, including failure.png, run.json, gateway-requests.jsonl, and the redacted app log.
• Final Release TRX bundle: e5404722239f4afa961258b7b5582204.
• Earlier Debug hang: ba6aa16080e340ab98bb98811d9821f6.

Artifacts are retained in the coordinating session and will be supplied to the fix session. These identifiers are not public download links.

Investigation boundaries

Start with the real session-selection path and ReactorItemsViewScrollController / InitialTailPositioner: request-key transitions, layout readiness, cached-session returns, and pending bring-into-view lifetime. Rule out test-driver side effects before assigning the cause.

Keep the fixture harness and the product fix in separate PR scopes. Add focused regression coverage, preserve normal scrolling and scroll-away behavior, and use the populated fixture for native runtime proof when safely available. Do not introduce extent-only scrolling, remove virtualization, replace the real provider, or weaken the 240-message test.

Isolation requirement

Do not use installed pairing data, existing Gateway credentials, or the default WSL distro. Fixture runs require owned profiles, ports and identities plus the explicit host-side-effect isolation guards. Do not launch a main-branch/older app with only OPENCLAW_TRAY_DATA_DIR: loopback WSL keepalive and OS registration paths are not fully isolated by that variable alone.

Start with scripts\test-gateway-fixture.ps1 and GatewayFixtureUiTests.SessionPickerSwitchesRealHistoriesAndShowsMessage240AtBothWidths, then inspect the real session-selection path through ReactorItemsViewScrollController and InitialTailPositioner. Use the failing proof bundle and rule out UI Automation timing before assigning a cause. Done means returning to the populated session naturally shows its final message, with focused regression coverage and preserved virtualization and scroll-away behavior.