This is a comment left during a code review.
Path: ui/src/ui/controllers/chat.ts
Line: 712-722

Comment:
**Unowned-branch silently drops `aborted`/`error` for `undefined`-runId payloads**

With `runId` now optional, any `aborted` or `error` event that arrives without a `runId` while an active run is in progress falls into the foreign-run branch and returns `null` (line 721) without clearing `chatRunId`, `chatStream`, or `chatStreamStartedAt`. If the server ever sends an `aborted` or `error` terminal event for the current active run without a `runId` (e.g. a timeout path or a gateway-level abort that doesn't carry run metadata), the typing indicator will be permanently stuck — the inverse of the bug this PR is fixing. The PR implicitly relies on the guarantee that all terminal events for the active run always include `runId`; that assumption is worth a code comment here.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: ui/src/ui/app-gateway.ts
Line: 588

Comment:
**Behavior change for `undefined` `payload` is benign but unintentional**

Removing the `payload?.runId &&` guard means that when `payload` itself is `undefined` and `activeRunId` is set, `payload?.runId` evaluates to `undefined`, so `undefined !== activeRunId` is `true` and the function now returns `true` instead of the prior `false`. The practical impact is nil — an `undefined` payload produces `null` from `handleChatEvent` and fails the `isTerminalChatState` check, so neither the deferred-reload nor the history-reload branch can fire. But the stated intent of the PR is only to treat *"payloads present but without a runId"* as foreign; adding a guard like `payload != null && payload.runId !== activeRunId` would make that intent explicit.

How can I resolve this? If you propose a fix, please make it concise.