Clean up desktop backend readiness polling diagnostics

[badcuban]

Priority: P2

Why

Desktop startup readiness polling currently records expected connection-refused attempts as trace failures while the backend is still booting. That makes Diagnostics look worse than the actual state and can hide real startup failures.

Diagnostics evidence

From C:\Users\Will\.t3\userdata\logs\desktop.trace.ndjson*:

• 300 desktop failures were http.client GET transport errors against http://127.0.0.1:3773/.well-known/t3/environment.
• Current BadCode install-path runs contributed 36 of those failures on May 26, 2026; older t3-code-desktop traces contributed the rest.
• desktop.backendManager.waitForHttpReady had 18 spans over 1s, average about 8.9s, max about 14.8s.
• DesktopBackendManager.waitForHttpReady() intentionally retries until the backend responds, so individual failed polls are usually expected during startup.

Acceptance criteria

• Expected backend readiness polling misses do not appear as individual diagnostics failures.
• A real backend startup timeout still emits one actionable warning/error with elapsed time and target URL.
• Startup UI can distinguish backend still starting from backend failed.
• Add coverage for successful startup after transient readiness failures.

[badcuban]

Completed in the 0.0.2-0.0.4 startup diagnostics work. Expected backend readiness polling is now retried with tracing disabled for the transient HTTP misses, while timeout failure still reports one actionable readiness error. Covered by DesktopBackendManager tests.