fix(dashboard): topology reflects connection health + clears finished requests

[danscMax]

What

The home-dashboard provider topology only coloured nodes from live/recent traffic.
Between requests — and right after a restart — the map went blank even though 50+
connections were healthy, which reads as "I lost all my providers". Two independent
root causes, fixed together.

1. Stuck-green latch (live pipeline)

request.completed / request.failed are declared in the dashboard event map and
consumed by useLiveRequests to drain the active-request set, but they were never
emitted — only request.started was (chatCore.ts:410). So a node's green "active"
pulse was a one-way latch: it lit on request start and only cleared on a page reload,
accumulating over a session and disappearing on restart.

Fix: emit the terminal event from persistAttemptLogs (the per-attempt completion
point, correct for both streaming and non-streaming), keyed by the same traceId as
request.started, via a pure resolveRequestLifecycleEvent() helper (2xx/3xx and no
error ⇒ request.completed, else request.failed). Deferred with setImmediate off
the response hot path, mirroring request.started.

2. No at-rest state (visualisation)

The map had nothing to show when idle. Each node is now coloured by connection
health (green connected / red error / grey idle) as a base layer; live and recent
traffic still take precedence and pulse brighter on top. edgeStyle() gains an
optional trailing healthy param (static dim green) and StatusDot a pulse prop
(static dot for connected-at-rest) — both backward compatible, so the Combo/Compression
studios that share the flow palette are unaffected. Legend "Active" → "Connected".

Validation (Hard Rule #18)

• tests/unit/topology-request-lifecycle-emit.test.ts — resolveRequestLifecycleEvent
  success / failure / token-alias units + guards that the emit exists and that
  traceId is threaded into persistAttemptLogs (pairs with request.started).
• tests/unit/topology-connection-health.test.ts — health derivation + node/edge wiring.
• tests/unit/ui/edgeStyles.test.ts — new healthy edge variant + error > active > last > healthy precedence.
• npm run typecheck:core clean; npm run lint clean; existing topology/edge suites green (Node + Vitest).
• Verified the live WS pipeline on a running instance: firing a real request delivered
  request.started on the dashboard WS, confirming the in-process eventBus → embedded
  WS-server path works. The new terminal emit rides the exact same path and is unit-tested.
• Node states rendered and eyeballed in light and dark themes (connected/active/error/idle).

Scope

No API or DB-schema changes. Security- and PII-sensitive paths untouched. Helper
signature additions are backward compatible.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[diegosouzapw]

Thanks for tracking down both root causes — the "stuck green" latch is confirmed real (grepped the release branch: request.completed/request.failed are declared in types.ts but were never emitted anywhere before this PR). resolveRequestLifecycleEvent and the edgeStyle/StatusDot unit tests all pass for me locally (17/17 across the three files).

Two things to fix before merge:

1. The branch currently has real conflicts against release/v3.8.49 in HomeProviderTopologySection.tsx and edgeStyles.ts (a sibling PR already landed the "Active"→i18n tCommon("active") swap and bumped idle edge opacity 0.2→0.3). Please rebase; keep your healthy state addition but reuse the i18n legend and the new idle opacity.
2. Your new legend label ("Connected") is hardcoded English — please route it through next-intl like the rest of that component instead of a literal string, since the sibling change on release already moved "Active" into the message catalog.

Note: the pure logic (resolveRequestLifecycleEvent, edgeStyle precedence, per-provider health derivation) is unit-tested and I ran it green — nice work there. The on-screen coloring/pulsing itself is UI-only and I haven't visually verified it on a running instance; a screenshot or two (light+dark) alongside your existing claim would help reviewers confirm.

[diegosouzapw]

Good news — the two conflicts from last review are resolved now. CI is currently red, but that's a shared base/infra issue hitting the whole PR queue right now (confirmed identical failure signature on an unrelated PR), not something in your diff. We still owe you a check on the i18n label item flagged earlier; will confirm once the base-red is cleared and CI re-runs green.

[diegosouzapw]

Validated in local merge-train runs 4+5 on 192.168.0.113 @ a00def8f1/477d9f4d3 (11-PR batch: static gates green ×2; test:unit union green — 24512/24529 + 24504/24521, residual fails proven environmental (/tmp stale) + timing-flake (6/6 isolated); vitest 260/260 on the equivalent local tree). Suite logs: /srv/omniroute-train/.claude/worktrees/merge-train-20260719-{231?,233341}-suite.log + /tmp/mt-full.log