fix(client): fall back from discover for any non-modern error

[ip2a]

Fixes #1040.

Problem

ClientLifecycleMode::Auto only fell back to the legacy initialize
handshake when server/discover failed with -32601 (METHOD_NOT_FOUND).
Legacy servers commonly reject an unknown pre-initialize request with other
implementation-defined errors (-32600, -32602, session-middleware errors),
so Auto broke against servers that previously worked.

Approach

Classification happens inside discover_startup, where the full context
(request id, response correlation, transport state) is still available — not
after the fact on ClientInitializeError, where that context is gone.

discover_startup returns a DiscoverOutcome:

• Modern — discover succeeded.
• Legacy(error) — the probe received a complete, correlated JSON-RPC error
  whose code is not a modern-era rejection. The transport delivered a full
  response and is ready for the next request, so a legacy initialize can
  follow on the same connection.
• Err(error) — everything else (transport failure, uncorrelated response,
  modern rejection, client-side state). Surfaced, not retried.

Auto simply matches the outcome. No methods on ClientInitializeError, no
downcast, no transport-specific types leaking into the lifecycle layer.

Two additional fixes that fall out naturally:

• Response correlation: expect_response now checks the request id on
  both success and error responses. Previously error responses skipped id
  correlation entirely. A new UncorrelatedErrorResponse variant surfaces
  responses that cannot be tied to the request.

• Fallback failure preservation: when both discover and the legacy
  fallback fail, a LegacyFallbackFailed compound error preserves both
  phases instead of discarding the discover error.

A silently legacy server that ignores the probe and hangs expect_response
is a separate concern (needs a discover timeout); tracked in #1142.

Tests

The existing lifecycle tests verify the behavior end-to-end: -32601,
-32600, and -32602 discover responses trigger fallback; -32021 and
-32020 are surfaced. The client-initialization test was fixed to echo the
real request id (it previously hardcoded 1 against an id provider that
starts at 0, which only worked because error responses were never
correlated).

Scope

Non-JSON HTTP responses (e.g. a legacy server returning a plain-text 422) are
not covered by this PR. Recognizing them as a legacy signal requires the
transport layer to carry a structured HTTP-status signal across the transport
boundary, which is an architectural change best discussed separately.

[ip2a]

Redesigned per your feedback. Replaced the Err(_) + modern-code carve-out
with ClientInitializeError::indicates_legacy_server: an exhaustive match
that falls back only on legacy signals (non-modern JSON-RPC error, closed
connection, unexpected response, non-auth transport error) and surfaces the
rest (modern rejections, auth/scope gate, client state). Added
is_authorization_failure for the 403 gap; test_legacy_server_classification
pins each variant.

Three calls I'd like your input on:

1. ConnectionClosed falls back. On stdio the transport is dead so
   legacy_startup's send fails and masks the original error; on HTTP a new
   initialize POST can still work. Kept fallback, lean that way but ok to
   surface instead.
2. ExpectedInitResponse / ExpectedInitResult / ConflictInitResponseId
   fall back — rare, transport still alive, seemed worth a try.
3. Non-auth TransportError (IO) is lumped with non-JSON 400; both fall
   back. Splitting needs a per-transport downcast, didn't seem worth it.

[ip2a]

Rewrote this to classify inside discover_startup instead of on the error
type. It now returns DiscoverOutcome::Modern or DiscoverOutcome::Legacy,
and Auto just matches on it — no indicates_legacy_server, no downcast,
no transport types in the lifecycle layer.

The three open review comments are addressed by the rewrite:

• ConnectionClosed: doesn't enter the fallback path at all (it's not a
  JsonRpcError, so discover_startup returns Err and Auto surfaces it)
• mismatched response id: expect_response now correlates ids on error
  responses too; UncorrelatedErrorResponse is surfaced, not retried
• non-JSON HTTP responses: out of scope for this PR. Needs the transport
  to carry a structured signal, which I'd rather discuss separately

[DaleSeo]

Response-scoped errors without an ID should remain available to the legacy classifier.

Suggested change

	}
	}
	None => ClientInitializeError::JsonRpcError(error.error),

[DaleSeo]

In ClientInitializeError::auth_challenge and ClientInitializeError::is_authorization_required, which drives reactive OAuth, the new wrapper hides fallback 401/403 challenges and causes authorization-required fallback errors to return false. Recurse into the fallback error so callers keep the documented classification behavior.