rust: `Client::resume_session` errors do not say which stage failed, or whether the session's history could not be loaded

[Lukaze]

Summary

Client::resume_session returns one Error for every failure along the resume path:

• the session.resume JSON-RPC reply itself;
• decoding its result (SessionIdMismatch, JSON);
• the follow-up setup calls the SDK makes after a successful reply (the MCP auth-interest registration, then finish_session_setup's options update, which disconnects the session when it fails).

Only a reply whose message contains "Session not found" is typed (ErrorKind::Session(NotFound)). Every other failure becomes Error::from_rpc with the CLI's message text.

So a host cannot tell apart:

1. the CLI refused to load the session's stored history (the transcript exists but could not be restored), where the right response is to stop and tell the user rather than silently start a new, empty session;
2. a non-history fault on the same reply (authentication, invalid parameters, a concurrent-handle race), which is often transient;
3. a failure in the SDK's own post-resume setup, after the CLI had already loaded the session.

The only way to separate them today is to match on free-form message text, which is fragile across CLI versions.

Affected versions

github-copilot-sdk (Rust) 1.0.14 and 1.0.15, with Copilot CLI 1.0.85 through 1.0.89.

Observed

Captured with Copilot CLI 1.0.89 and github-copilot-sdk 1.0.15 (paths, ids and the quoted transcript line replaced by placeholders):

• The stored history cannot be loaded (the session's events.jsonl has an unparseable first record):

  code=-32603
  Request session.resume failed with message: session resume failed: Failed to read JSONL from <path>/events.jsonl: Invalid event at line 1: expected ident at line 1 column 2. Event: <line text>
  

• The session has no stored events (an empty events.jsonl):

  code=-32603
  Request session.resume failed with message: Failed to load session events: Session not found: <session-id>
  

Both come back as the same generic JSON-RPC code, -32603. The SDK types only the second one, ErrorKind::Session(NotFound), because its message contains "Session not found". The first one reaches the host as Error::from_rpc with free-form text. So do non-history faults on the same reply and failures in the SDK's own post-resume calls.

The first message also quotes the offending transcript line verbatim after Event: . A host that logs the error text therefore logs conversation content, unless it strips that text itself. A structured error would avoid the need to parse or scrub it.

Expected

One of the following, in order of preference:

• (a) The SDK types the stage: for example ErrorKind::Session(ResumeRejected { code, message }) for an error on the session.resume reply, distinct from ErrorKind::Session(SetupFailed { .. }) for the SDK's own post-resume calls.
• (b) The CLI gives "stored history could not be loaded" its own JSON-RPC error code, or a structured data field such as {"reason": "history_unloadable"}, and the SDK surfaces it as a typed kind, the way it already does for "Session not found".

Why it matters

A host that must never continue a conversation without its prior context has to refuse the turn when history cannot be restored. Without a typed signal, it must either refuse on every resume error, so transient faults read as lost history, or fall back to a fresh session, which silently drops the conversation's context.

Proposed fix

• The SDK side of (a) is local to Client::resume_session: wrap the session.resume call's error separately from the result decode and from finish_session_setup.
• (b) needs a CLI-side error code, which the SDK then maps the way it maps "Session not found" today.