public API naming and shape decisions drift without a referenced style guide

CONTRIBUTING.md を開き、既存のコードスタイルとリポジトリのパターンのみを参照していることを確認します。既存の API を変更せずに、公開 API の命名と型の形状の基準として、公式の Rust API Guidelines への参照を追加します。完了条件は、コントリビューター向けドキュメントからガイドと関連するチェックリストに明示的にリンクされており、API の整合は引き続きスコープ外であることです。

Description

While looking through the crate's public API, I noticed a few inconsistencies that suggest there's no referenced style-guide baseline behind naming/type-shape decisions:

• Some plain accessors use a get_ prefix while neighboring accessors in the same files don't, which reads as inconsistent with the Rust API Guidelines' C-GETTER convention.
• Identifier fields (session/task/tool-use/client id) are represented as bare String/Arc<str> rather than distinct types, so nothing stops one id kind being passed where another is expected.

No repo doc references a style guide, so it's unclear whether this is intentional or just drift. Simplest fix: state explicitly in contributor docs that code should be idiomatic and follow the official Rust API Guidelines (https://rust-lang.github.io/api-guidelines/) - its naming (C-*) and type-safety (C-NEWTYPE) checklists already cover both examples above, so this is a documentation change, not a new process to design. Bringing existing API (like the two examples above) in line with the referenced guide is a separate, breaking-change follow-up - worth tracking on its own once the guide itself is adopted, not part of this issue.

Reproduction Steps

1. rg -n "pub fn get_[a-z_]+\(" crates/rmcp/src - 8 matches, all plain field/derived-value accessors inconsistent with sibling accessors in the same files.
2. Compare SessionId/EventId/StreamId/task_id/tool_use_id/client_id field types across model.rs, task_manager.rs, transport/auth.rs - all bare String/Arc<str>/type aliases, no newtype.
3. Checked CONTRIBUTING.md and the repo for any reference to language-specific style guide - none found. CONTRIBUTING.md only says "follow existing code style" / "follow the repository's established patterns," with no concrete convention to check against.

Expected Behavior

Contributor docs cite an explicit style-guide baseline for public API naming/shape.

Actual Behavior

No such reference exists, so it's unclear whether naming inconsistencies like the above are intentional.

Logs / Evidence

• Rust API Guidelines: https://rust-lang.github.io/api-guidelines/
• C-GETTER: https://rust-lang.github.io/api-guidelines/naming.html#getter-names-follow-rust-convention-c-getter