build: Cargo.lock ignored + floating rmcp req — local and CI can resolve different rmcp APIs (ClientConfig)

[ajianaz]

Problem

Local cargo build -p tole-cli on develop cb2e244 failed while CI was green:

error[E0433]: cannot find `ClientConfig` in `rmcp::model`   (mcp.rs:305, :183)

Chain of causes:

1. Cargo.lock is git-ignored (.gitignore:2) — CI resolves dependencies FRESH on every run.
2. rmcp = { version = "3.3", ... } is a floating caret req.
3. rmcp 3.4.0 is now on crates.io and satisfies "3.3". CI resolves → 3.4.0 → has rmcp::model::ClientConfig → green.
4. Any machine with a stale lock (or a fresh resolve at a different time) can pin a different rmcp. rmcp 3.3.0 (still in the stale local lock) does not export ClientConfig → compile error.

Net effect: "what compiles" depends on when you resolved, not on the commit — a reproducibility hazard for a repo that ships a binary (tole-cli) and an embedder-facing core crate.

Suggested fix (pick one, owner's call)

• Commit Cargo.lock (recommended): standard for repos with binaries; pin rmcp at a known-good version (3.4.0 verified compiling today); CI keeps working unchanged (it already treats the lock as input when present). Note: cargo update -q on today's tree resolves rmcp 3.4.0 and cargo build -p tole-cli succeeds — verified.
• Or pin rmcp = "=3.4.0" (or =3.3.x) explicitly and keep the lock ignored — narrower, but every other floating dep keeps the same hazard class.

Acceptance criteria

• Fresh clone → cargo build --workspace compiles with the same dependency versions CI used on the same day, deterministically.
• CI and local builds can no longer disagree on rmcp's API surface.