LSP crash-loop failures not paced by StartableToolSet backoff gate (#4060 follow-up)

[aheritier]

Context

PR #4074 extended the StartableToolSet backoff gate to remote MCP HTTP errors and explicitly documented (in code comments and docs/tools/lsp/index.md) that LSP crash-loop pacing is not yet wired.

Problem

lifecycle.ErrServerCrashed — the sentinel produced when an LSP server process crashes repeatedly — is only produced inside the supervisor's internal watcher goroutine, and is never surfaced through supervisor.Start()'s return value. Because of this, startBackoffRetryable never sees it, and a persistently-crashing LSP server gets relaunched at full speed on every turn rather than being paced by the backoff gate.

Acceptance criteria

• Propagate lifecycle.ErrServerCrashed (or an equivalent classification) from the supervisor's watcher goroutine up through supervisor.Start()'s error return, so it reaches StartableToolSet.startLocked
• Decide whether ErrServerCrashed should arm the gate directly, or whether it needs translation into a *modelerrors.StatusError-compatible signal via the classifier
• Add focused tests: a simulated LSP crash-loop arms the backoff gate on the next turn; a clean LSP shutdown/non-crash failure does not
• Update docs/tools/lsp/index.md to remove the "not yet wired" caveat once implemented