Add typed AuthError variants once the runtime distinguishes auth-missing/invalid/unreachable

## Context

Companion to [github/copilot-agent-runtime#7485](https://github.com/github/copilot-agent-runtime/issues/7485) — the runtime today returns identical generic `-32603 internal_error` payloads for "no token," "invalid token," and "network unreachable." Once the runtime adds distinct codes (e.g., `-32001 AuthMissing`, `-32002 AuthInvalid`, `-32003 AuthUnreachable`), the SDK should expose them as a typed enum so consumers don't string-match.

## Proposed shape

```rust
pub enum Error {
Rpc { code: i32, message: String, data: Option },
// ...
Auth(AuthErrorKind), // new
}

pub enum AuthErrorKind {
/// No token configured. User needs to sign in.
Missing,
/// Token rejected by CAPI (401/403). User needs to reauth.
Invalid,
/// Transport failure talking to CAPI. Retry, don't reauth.
Unreachable { cause: String },
}
```

The SDK can map known runtime codes to `Error::Auth(...)` and leave anything else as `Error::Rpc { ... }`.

## What this lets consumers delete

In Copilot Desktop today (`src-tauri/src/error.rs:115-120`) we string-match three magic phrases:

```rust
pub fn is_copilot_auth_failure(&self) -> bool {
let message = self.to_string().to_ascii_lowercase();
message.contains("not authenticated")
|| message.contains("authenticate first")
|| message.contains("no authentication info available")
}
```

Plus the connectivity-tracker workaround in `handlers/auth.rs::emit_copilot_cli_auth_issue` whose only job is to second-guess whether the runtime's "not authenticated" really means "not authenticated" or "couldn't reach the auth service." Both go away with typed variants.

## Dependencies

Blocked on the runtime change ([github/copilot-agent-runtime#7485](https://github.com/github/copilot-agent-runtime/issues/7485)). No useful SDK work to land before the runtime distinguishes the cases on the wire.

---

  _{Generated via Copilot (Claude Opus 4.7) on behalf of @tclem}