feat: support separate model-visible aliases and MCP wire tool names

- [x] I have looked for existing issues (including closed) about this

## Feature Request

Allow an RMCP tool's model-visible name to differ from the server-advertised MCP tool name used for `tools/call`.

Rig's RMCP adapter currently uses `rmcp::model::Tool::name` both as the registered/model-visible tool name and as `CallToolRequestParams::name`. This works while both identities are identical, but it prevents clients from safely applying provider-compatible aliases or resolving collisions across MCP servers.

### Motivation

MCP tool names are protocol identities owned by the server and must be preserved when calling the server. The name exposed to a language model may need to differ:

- A provider may impose a stricter tool-name character set or length limit than MCP.
- Two MCP servers may advertise the same tool name, such as `fetch`.
- Sanitization can make distinct MCP names collide.
- A client may namespace tools so the model can route calls unambiguously.

Changing `Tool::name` to the model-visible alias makes the model declaration valid, but Rig then sends that alias in `CallToolRequestParams::name`. The MCP server receives an unknown tool name.

This affects Rig 0.41.0 and the current `main` implementation in `crates/rig-agent/src/tool/rmcp.rs`: `McpTool::name()` and `McpTool::execute_mcp()` both derive their name from the same `definition.name`.

### Proposal

Add a public RMCP registration path that accepts a model-visible name separately from the raw MCP definition, while preserving the existing methods as shorthand where both names are identical.

For example, the API could accept a registration value with:

```rust
pub struct RmcpToolRegistration {
pub model_name: String,
pub definition: rmcp::model::Tool,
pub client: rmcp::service::ServerSink,
pub timeout: Option,
}
```

The exact public shape can follow Rig's current tool architecture, but it should preserve these invariants:

- Provider tool definitions and toolset lookup use `model_name`.
- MCP `tools/call` always uses the original `definition.name`.
- The existing timeout, cancellation, `_meta`, structured-content, raw-result, and error behavior remains available.
- Existing `rmcp_tool(s)` and `rmcp_tool(s)_with_timeout` behavior remains unchanged when no alias is supplied.
- Tests cover a sanitized alias and two servers exposing the same raw tool name.

### Alternatives

- Mutating `rmcp::model::Tool::name` before registration makes the provider-facing name valid but corrupts the MCP wire identity.
- Wrapping every MCP tool in a generic dynamic tool can separate the names, but each Rig consumer must duplicate the RMCP adapter's timeout, cancellation, metadata, structured-result, and error handling.
- Requiring MCP servers to rename tools does not solve collisions across independently owned servers and makes provider-specific restrictions a server concern.