ServerHandler::get_tool is not scope-aware

[plusky]

rmcp 3.1's tower layer calls get_tool to cache tool input schemas for SEP-2243 Mcp-Param-* validation; it takes no RequestContext, so it cannot consult the caller's bearer scope. A read-scope caller sending Mcp-Param-* headers naming a write tool could in principle observe validate-vs-skip behaviour. It sits behind the bearer gate and leaks no bug data — but it is the one place the per-credential surface (#105) is not enforced. Revisit when adopting the 2026-07-28 revision (#34), which is what makes those headers meaningful. Found during #105's review.

Verified against merged #105 and the pinned rmcp 3.1.2 (2026-08-18): the schema cache in streamable_http_server/tower.rs is populated per name via ServerHandler::get_tool(&self, name) — no RequestContext in the signature — and bugwarden's impl serves the I13-pruned instance router, which prunes per deployment, not per credential; list_tools and call_tool remain the only per-credential points.

Blocked on #34: nothing before the 2026-07-28 revision makes Mcp-Param-* headers meaningful, so the revisit point is that adoption.

Acceptance criteria

• A read-scope credential naming a write tool in Mcp-Param-* headers observes the same validate-vs-skip behaviour as one naming a tool that does not exist — the schema lookup answers per credential, not per process.
• The bearer gate still fronts the lookup: no Mcp-Param-* validation path runs for an unauthenticated request.
• If rmcp's get_tool still takes no RequestContext at adoption time, the gap is either closed upstream or recorded in DESIGN.md as an accepted, bounded leak (validate-vs-skip only, never bug data).