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

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

Open CONTRIBUTING.md and confirm that it only refers to existing code style and repository patterns. Add a reference to the official Rust API Guidelines as the public API naming and type-shape baseline, without changing existing APIs. Done means contributor documentation explicitly links the guide and its relevant checklists, while API alignment remains out of scope.