Separate long-lived subscriptions from slow-span diagnostics

[badcuban]

Priority: P1

Why

Diagnostics slow-span counts should point at operations that need performance work. Right now long-lived WebSocket subscriptions are counted as slow spans because their duration is the lifetime of the subscription, not the latency of a completed operation.

Diagnostics evidence

From C:\Users\Will\.t3\userdata\logs\server.trace.ndjson* on May 26, 2026:

• Slow-span aggregation includes spans like ws.rpc.orchestration.subscribeThread, RpcClient.orchestration.subscribeThread, ws.rpc.subscribeVcsStatus, ws.rpc.subscribeServerConfig, and http.server GET with durations around 1,696,000 ms.
• These are stream/subscription lifetimes ending when the client disconnects or refreshes, not necessarily performance regressions.
• The same trace window had 784 spans over 1s and 85 spans over 5s, so subscription lifetimes can hide actionable slow operations.

Acceptance criteria

• Diagnostics separates long-lived streaming/subscription spans from request/operation latency spans.
• Slow-span counts prioritize completed bounded operations.
• Subscription spans can still be visible in a separate section if useful for lifecycle debugging.
• Add tests around slow-span classification for WebSocket/RPC subscriptions.

[badcuban]

Backlog triage update: this is prioritized for the next practical release because the project direction is now personal local-tool reliability/performance/UX rather than public marketing or hosted web. This should stay near the top because it keeps diagnostics useful and reduces noise around long-lived subscriptions.

[badcuban]

Closed after verification on main (a8e4e801): trace diagnostics now separates subscription/websocket-upgrade spans from bounded slow-operation spans, exposes subscription diagnostics separately, and has regression coverage.