[Fix] Websocket and Log Viewer

[antonio-amjr]

Fix: project-chip/certification-tool#1072
Depends on Backends: project-chip/certification-tool-backend#347

Description

Companion fix to the backend PR for #1072. Two independent problems remained on the CLI side even after the backend stopped stalling and truncating logs:

1. The CLI could silently disconnect from the backend's WebSocket the instant it saw the "run finished" signal, before a final trailing batch of log messages had arrived — losing the last few lines of a run.
2. The browser-based real-time log viewer (--log-streaming) would freeze during large runs: it received log lines faster than it could render them, so its internal queue grew into a multi-minute backlog. The view looked "stuck," even though the connection was healthy — it was just always showing stale content instead of what was happening right now. Since this viewer is the only place users can see SDK trace output live (used to decide how to answer test prompts), a stale view is effectively as broken as no view.

Changes

• Don't disconnect immediately on run-completion. The WebSocket loop now keeps draining for a short grace period after seeing the terminal state, instead of closing the instant that message arrives, so any trailing log batch the backend
  is still sending isn't dropped.
• Process log batches without blocking the connection. Large incoming batches are now processed with periodic yields back to the event loop, instead of one big synchronous loop, so the connection stays responsive even under a heavy burst.
• Cap the live viewer's pending queue. If incoming log lines arrive faster than the browser can render them, the oldest unrendered entries are now dropped so the view stays within a few seconds of real time — instead of accumulating an
  ever-growing backlog that only "catches up" long after the test has already finished. This does not affect the saved log file or the full downloadable log, only what's shown live. (An earlier version of this fix hid raw SDK trace content from
  the live view entirely to solve the freeze — that broke the actual reason the live viewer exists, since it's the only place to read trace context while answering a test prompt. This version keeps everything live and fixes the actual backlog
  instead.)
• "Download Logs" now points at the backend's own log endpoint instead of the CLI's own process. The previous implementation served the file from the CLI's local, short-lived HTTP server — which shuts down the moment the run finishes, i.e. right when someone would naturally want to click "download." Rather than trying to keep that ephemeral server alive or fall back to an incomplete in-memory reconstruction, the button now links directly to the backend's existing, durable
  log-download endpoint (the same one the web UI's download has always used successfully). This is the standard fix for this kind of problem — never serve a "download" from a transient process; point at wherever the artifact durably lives.

Verified

Watched the live viewer through two full TC-ACE-2.4 runs: content stays current throughout (brief freezes), and the CLI's saved log matches the backend's copy.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request