[Perf] Windows Hub idle: OpenClaw.Tray.WinUI pegs one CPU core continuously (~100%+), causing window-drag jank

Describe the bug

On Windows Hub (OpenClaw Companion) v2026.7.1-2, the OpenClaw.Tray.WinUI process idles at ~100% of one CPU core continuously (even when the window is idle and nothing is happening). This makes dragging/moving the main window noticeably janky (UI/rendering thread is busy).

Evidence (measured on this machine)

OpenClaw.Tray.WinUI (PID 7948) CPU samples, idle, window open but not being interacted with:

sample 1: +3.17s CPU in 3s wall  (≈106% of one core)
sample 2: +3.12s CPU in 3s wall  (≈104% of one core)
sample 3: +3.12s CPU in 3s wall  (≈104% of one core)

Meanwhile the OpenClaw Gateway node process is idle (~0% CPU), and overall system load is only ~10% with ~7 GB free RAM — so this is not a resource-starved machine; the WinUI app is burning a core on its own.

Expected behavior

When the window is idle (no messages streaming, no animation active), OpenClaw.Tray.WinUI CPU usage should be near 0%.

Actual behavior

The process continuously pegs one core (~100%+), causing window-drag jank and elevated power/heat.

Possible cause direction

Likely a WinUI3 rendering/layout busy-loop (animation, progress indicator, or layout-cycle) that never idles. Related work already exists in this repo: #1279 "fix(chat): coalesce Publish() bursts to prevent WinUI3 layout-cycle crash". A sustained single-core busy loop strongly suggests a render/layout effect that is scheduled unconditionally instead of only when needed.

Environment

• OS: Windows 10 Pro 22H2 (build 19045, x64)
• OpenClaw Companion (Windows Hub): v2026.7.1-2
• OpenClaw Gateway: 2026.8.1 (local, loopback bind)
• GPU: Intel UHD 630 (integrated) + virtual display adapters from remote-control software (GameViewer)

Repro

1. Start OpenClaw Companion and let it idle (no chat activity, window visible).
2. Observe CPU usage of OpenClaw.Tray.WinUI — it stays at ~100% of one core.
3. Try dragging the main window — it lags/stutters.

Suggested fix

Ensure render/layout effects are only scheduled when the UI actually needs an update (e.g. coalesce/unschedule idle animations and progress updates), so the app idles at ~0% CPU when nothing is happening.

Reproduce the idle CPU usage in the OpenClaw.Tray.WinUI process, then inspect the WinUI rendering and layout paths related to the behavior. Read issue #1279 for existing context on Publish() bursts and layout cycles. Done means the visible window remains responsive and idle CPU usage is near 0% without breaking active updates.