improve: lock in byte-stability of MCP and protocol payloads (cache-stability audit)

[jhonatanjunio]

Target

src/commands/mcp_server.rs and src/commands/protocol.rs — the surfaces that land in Claude's cacheable prefix.

Current behaviour

Claude's prompt cache invalidates tools → system → messages in order. Any byte change at a given layer invalidates that layer and everything after it. With a warm cache the same session can cost ~10× less (cache reads are ~10% of standard input price).

For squeez specifically:

Surface	Cacheable?	Risk
commands::protocol::full_payload()	Goes into tool-result text; cached as part of the prior turn	Any drift across calls would push it out of cache
mcp_server::tools_list_response	Goes into MCP tools layer	Any drift invalidates everything below
mcp_server::initialize_response	Sent once per MCP session	Stable except for id
init banner	Captured by SessionStart hook → message history	Stable given same input state
wrap header	Fresh tool-result text every call	elapsed_ms naturally varies — expected

We have no test that ENFORCES this. Today's code is cache-stable by inspection, but the next refactor could silently regress us and burn an order-of-magnitude more tokens before anyone notices.

Proposed change

1. Add tests/test_cache_stability.rs with regression-guard assertions:
   • protocol::full_payload() byte-identical across 100 invocations.
   • protocol::SQUEEZ_PROTOCOL + SQUEEZ_MARKERS_SPEC compose deterministically.
   • persona::text(...) returns the same &'static str (pointer-equal).
   • MCP tools/list response byte-identical apart from the JSON-RPC id.
   • MCP initialize response byte-identical apart from id.
   • MCP tools/call for squeez_protocol byte-stable across 20 invocations.
2. Doc comments on full_payload, tools_list_response, and initialize_response referencing the cache-stability requirement so contributors know which strings must stay deterministic.

No code-behaviour change expected — the audit confirmed everything is already stable.

Expected impact on benchmarks

None — pure tests + doc comments. Adds 7 new integration tests; lib suite unchanged.

Confirmations

• I've searched existing issues and this isn't a duplicate.
• This is additive or equivalent — not a behaviour-breaking change to existing handlers.