Parity backlog: high-level session/client methods exposed in Rust SDK only

[tclem]

The Rust SDK's Cross-SDK Consistency Review on PR #1164 surfaced several methods that the Rust SDK promotes to first-class Session / Client methods, but which are reachable from other SDKs only via the lower-level generated RPC layer (or not at all).

These are real protocol methods backed by the CLI server. The Rust SDK established a richer high-level surface; the other SDKs are consistent with each other but lag behind. Tracking here as a parity backlog item across Node/Python/Go/.NET.

Methods the Rust SDK exposes at the high level

Method	RPC call	Status in other SDKs
Session::get_model()	session.model.getCurrent	Generated RPC only
Session::get_mode() / set_mode()	session.mode.get / session.mode.set	Generated RPC only
Session::get_name() / set_name()	session.name.get / session.name.set	Generated RPC only
Session::list_workspace_files() / read_workspace_file() / create_workspace_file()	session.workspace.*	Not exposed
Session::read_plan() / update_plan() / delete_plan()	session.plan.*	Not exposed
Session::start_fleet()	session.fleet.start	Not exposed
Session::send_telemetry()	session.sendTelemetry	Not exposed at session level
Client::get_quota()	account.getQuota	.NET generated only

Why it matters

• Consumers shouldn't have to drop into the generated RPC layer for first-class Copilot session features.
• Names, signatures, and ergonomics across SDKs should converge so the Rust SDK isn't a moving target.

Suggested approach

Each SDK could pick this up independently — most additions are mechanical wrappers around the existing generated RPC types. We should agree on naming first so we don't end up with getModel / Model / GetCurrentModel / get_model style drift.

The Rust signatures in rust/src/session.rs and rust/src/lib.rs (PR #1164) can serve as the reference shape. If a different SDK has a stronger reason to deviate, that's worth a discussion before landing.

Out of scope

Idiomatic differences like Rust's subscribe() returning a tokio::sync::broadcast::Receiver vs Node's callback on(handler) are correctly idiomatic for each language — the consistency review flagged these as expected, and they don't belong here.

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