feat(health): expose WebUI stream runtime diagnostics

[AJV20]

Thinking Path

• WebUI chat slowness/stuckness is hard to diagnose from the browser when SSE streams exist but no tab is attached or events are buffering offline.
• /health?deep=1 already collects operational checks for supervisors and support workflows.
• Adding non-sensitive stream counters there gives operators evidence without exposing prompts, tool arguments, event payloads, paths, or secrets.

What Changed

• Adds StreamChannel.diagnostic_snapshot() with subscriber and offline-buffer counts.
• Adds _stream_runtime_diagnostics() to summarize active WebUI SSE streams.
• Includes the runtime summary in deep health checks under checks.stream_runtime.
• Adds regression coverage for per-channel counters and aggregate stream diagnostics.
• Updates CHANGELOG.md.

Why It Matters

When WebUI feels slower than a messaging chat, operators can now tell whether the server is actively streaming, whether any browser subscribers are attached, and whether offline events are accumulating.

Verification

• python -m pytest tests/test_webui_runtime_diagnostics.py -q -o 'addopts='
• python -m py_compile api/config.py api/routes.py
• git diff --check

Risks / Follow-ups

• The endpoint exposes stream ids and counts only; it intentionally avoids payloads and local filesystem/process details.
• A follow-up UI could surface these counters in the control center or troubleshooting panel.

Model Used

OpenAI gpt-5.5 via Hermes Agent, with repository tools and targeted pytest/py_compile verification.

[nesquena-hermes]

Phase 0 quick note — agent review queued, holding for cron tick

Thanks @AJV20 for the diagnostics/surface-context/dashboard-link burst. These three (#2523 + #2524 + #2533) are well-scoped and CI-eligible, but they're <6 hours old from a first-time contributor with several other in-flight PRs (#2527 + #2526 are getting maintainer-review treatment separately).

For this sweep I'm holding all three out of the batch and letting the agent-review cron pick them up on its next tick — that's a structured per-PR diff/test/integration read with a recap comment, after which the parallel reviewer typically follows. Once both have landed, they'll be eligible for the next batch.

Nothing wrong with the PRs themselves at a glance — the burst pattern just means "scrutiny stays per-PR, not 'batch everything because they're all small'". Will revisit on the next sweep.