chore(deps): land rmcp 3.1 and adopt regex! from regex 1.13

[coseto6125]

What

Two things the recent dependabot wave left on the table:

1. rmcp 2.2 → 3.1.0 — unblocks the bump dependabot could not land on its own
   (chore(deps): bump rmcp from 2.2.0 to 3.0.0 #668 / chore(deps): bump rmcp from 2.2.0 to 3.0.1 #670 / chore(deps): bump rmcp from 2.2.0 to 3.1.0 #673 all stalled on a compile break).
2. Adopt regex! from regex 1.13 — replaces the two hand-rolled
   OnceLock<Regex> accessors with the upstream macro.

Plus a full cargo update so the lockfile matches the latest compatible
versions across the tree.

rmcp 3.1 migration

rmcp 3.0 tracks MCP 2026-07-28. The only break that reaches this crate is
SEP-2322 MRTR:
ServerHandler::call_tool now returns CallToolResponse (a three-variant enum:
Complete / InputRequired / Task) rather than CallToolResult.

ecp mcp serve is spawn-mode only — every tool call runs the subcommand to
completion in a single shot — so the response is always Complete. The
migration is the From<CallToolResult> conversion at the one return site.

Everything else in the 3.0 breaking list is inapplicable here: sessionless
Streamable HTTP, the stateless discovery lifecycle, subscriptions and the tasks
extension are all HTTP-transport or client-side concerns, and this server is
stdio + serve_server.

regex! adoption

regex 1.13 ships a regex! macro that expands to exactly the
static Lazy<Regex> pattern this repo was writing by hand. Two sites converted:

• hook/pre_tool_use.rs::glob_stem_re — hot path (PreToolUse fires on every
  Grep / Glob / Bash); the doc comment explaining why it is compiled once stays.
• event_topic/normalize.rs::get_version_regex

Semantics are identical (process-lifetime lazy compilation), so this is
boilerplate removal, not a perf change. The regex floor moves to 1.13.0 in the
two crates that use the macro.

Deliberately not converted: the module-level named statics in
fetch_shape/ carry doc comments and long patterns. Inlining those into their
call sites would bury a 100-char pattern inside a for header and drop the
documentation — worse on both counts.

Other bumps reviewed, nothing to adopt

crate	change	verdict
etoon 0.6 → 0.7.1	encoder collapses nested field groups + keyed tabular form; no API change	smaller TOON output, automatic
clap 4.6.x	help/derive fixes only	nothing to use
rayon 1.12	new par_array_windows	no call site wants it
similar 3.1.2	fixes Algorithm::Lcs deadline-fallback panic	we use default Myers with no deadline — unaffected
toml 1.1.4, aho-corasick 1.1.5, ignore 0.4.33	patch fixes	lockfile only

Verification

• cargo test -p ecp-analyzer — 2513 passed, 0 failed
• cargo test -p egent-code-plexus --tests — 1269 passed, 0 failed
• cargo test -p ecp-mcp — 46 passed, 0 failed
• cargo clippy --workspace --all-targets — clean

Wire compatibility, checked by hand

The risk in an MCP major bump is the response envelope, and no test covers it —
server_smoke_test.rs asserts the tool list, not the serialized shape. So a
real stdio handshake against the built binary:

$ ecp admin mcp serve < probe.jsonl
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-06-18",...}}
{"jsonrpc":"2.0","id":3,"result":{"content":[{"type":"text","text":"summary:\n ..."}]}}

A tools/call under the legacy protocol comes back as plain
{"content":[…]} with no resultType — byte-identical to what rmcp 2.2
emitted. That is rmcp's own strip_result_type_for_legacy_peer
(handler/server.rs:256) doing the work at the framework layer, below this
crate, so existing clients see no change. No test was added for it: it would be
asserting upstream framework behaviour, not ours.

[github-actions]

ecp impact cache (0 symbols) — internal, used by ecp dev pr-analyze

[]