web: opening an actively-streaming session hangs at "Loading…" (renderer infinite loop, 100% CPU) — regression since 0.39.x

Summary

Opening a session that is actively streaming a live turn hangs the web UI at "加载中…" forever. The browser renderer process pegs 100% CPU — the page's main thread is stuck in a JS infinite loop and never recovers. Idle sessions, even very large ones, load instantly.

Regression: not present in 0.38.0, reproduced on 0.39.1 and 0.40.1 (official binaries, no modifications).

Environment

• kimi-code: 0.39.1 and 0.40.1 (official darwin-arm64 binaries from code.kimi.com; sha256 of the 0.40.1 binary matches the published manifest)
• OS: macOS (Apple Silicon)
• Browser: Chrome (also reproduced in a fresh headless Chrome profile, so not extension/cache related)
• Server started with: kimi web --no-open --port <port> in the project directory

Steps to reproduce

1. Have a session with a long-running, actively streaming turn (our repro session had a running background subagent and streaming tool calls; the turn streams for minutes).
2. While the turn is still running, open that session in the web UI (/sessions/<id>), or reload the tab.
3. The page shows "加载中…" and never finishes. The Chrome renderer process sits at 100% CPU; the page's main thread is unresponsive (a DevTools-protocol Runtime.evaluate call gets no response for 3s+, 10/10 attempts).

Control experiments (same machine, same sessions, all official binaries)

• Transcript size is not the trigger — the 368 KB idle session renders instantly.
• The trigger is the session being live/streaming at open time. After the turn finishes, the same session can be opened again (consistent with what we observed interactively).
• Both 0.39.1 and 0.40.1 were tested as unmodified official binaries, so this is not caused by any local modification.

Notes

• Possibly related to #3112 (view-layer freeze involving the live-turn computed) — the trigger area overlaps (live turn rendering), but the symptom here is distinct: the whole page never mounts and the main thread spins at 100% CPU rather than just freezing updates.
• The 0.40.0 "connecting splash now shows the loading stage" improvement didn't help here — the hang happens after the splash, while the session transcript should appear.
• Happy to capture a Chrome performance profile or test a dev build if that helps.

Start with the web UI session route at /sessions/ and reproduce using kimi web --no-open --port <port> while a turn is actively streaming. Compare the session-loading and live-turn rendering path between 0.38.0 and 0.39.1, using Chrome’s performance tools to locate the main-thread loop. Done means an active streaming session mounts without the renderer hanging or reaching 100% CPU, while idle sessions still load.