[Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1)

Summary

OpenClaw Companion v2026.7.1 can become unresponsive when switching to a session whose history load returns approximately 200 messages. The gateway remains healthy while the native WinUI stops updating, and Windows records AppHangB1.

This appears related to synchronous history projection/snapshot rendering, but is distinct from the per-event streaming flood tracked in #1150 and its candidate fix #1158.

Environment

• OpenClaw Companion: v2026.7.1
• Release commit: 4206611f2b2e47cd575e1c8aa94e3e7708f6dd96
• Windows desktop client: OpenClaw.Tray.WinUI.exe

Reproduction

1. Have a session with enough history for the Companion to load the approximately 200-message history window.
2. Switch from another session to that session.
3. Wait while the history response is projected and the resulting snapshot is rendered.

Reproduced on 2026-08-16 around 12:04 local time.

Actual behavior

• The native WinUI becomes unresponsive or stops visually updating.
• Windows records AppHangB1.
• Gateway health remains OK during the UI hang.

Expected behavior

Switching sessions and loading the bounded history window should remain responsive, including for histories containing many agent/tool events.

Exact-release source path

In the v2026.7.1 source, OpenClawChatDataProvider folds the loaded history (up to 200 messages) into timeline state and publishes the resulting snapshot. The Changed handler in OpenClawReactorChatRoot then calls setSnapshot(args.Snapshot), triggering the native WinUI/React render.

Even though this is one publication rather than the per-event publication storm in #1150, projecting and synchronously rendering a large snapshot immediately after a session switch can saturate the UI thread.

Relevant source:

• src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs
• the OpenClawReactorChatRoot snapshot Changed handler

Why this is not a duplicate of existing reports

• #1150 is the canonical report for UI saturation under a high-rate live agent-event stream. Draft PR #1158 bounds/coalesces those per-event paths, but does not appear to batch the initial history projection/render during a session switch.
• #860 was closed by merged PR #898, which virtualized chat timeline rows. That merge is already an ancestor of v2026.7.1, so this hang reproduced with row virtualization present.

Suggested fix/validation area

• Batch or incrementally project history where practical.
• Avoid a large synchronous full-timeline render on the UI thread after session selection.
• Add a current-head WinUI responsiveness test that switches into a session with 200 varied history messages, including dense agent/tool entries.
• Preserve scroll restoration, selection, and terminal event state while batching.

Crash scope

There was also one separate 2026-08-13 crash involving CoreMessagingXP.dll. There is not enough evidence to attribute that crash to this history-load hang, so this report is limited to the recurring AppHang/UI-saturation behavior.