Add MCP CacheableResult caching hints (ttlMs and cacheScope) to list and read results

Documented steps

1. Read https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching (SEP-2549). Caching hints are new in the 2026-07-28 revision.
2. Include ttlMs and cacheScope on results with resultType 'complete' returned by server/discover, tools/list, prompts/list, resources/list, resources/templates/list and resources/read. The spec states servers MUST include them.
3. Set ttlMs to an integer number of MILLISECONDS the client may consider the result fresh — semantically equivalent to HTTP Cache-Control max-age. Servers MUST provide ttlMs >= 0.
4. Use ttlMs 0 to mean immediately stale (the client may re-fetch every time).
5. Set cacheScope to exactly 'public' or 'private'. 'public' means no user-specific data, so any client, shared gateway or caching proxy may store and serve it to any user. 'private' means the response may be reused only within the same authorization context and MUST NOT be shared across authorization contexts.
6. Apply the SAME cacheScope to every page of a paginated list response. Servers MUST NOT switch scope between pages of one list request.
7. You MAY vary ttlMs per page; each page is cached independently with its own freshness clock and there is no cross-page consistency guarantee.
8. Omit caching hints from interim resultType 'input_required' results — those are explicitly not cacheable.
9. Client: compute freshness as now < received_at + ttlMs. Treat an absent ttlMs as 0 (this should only happen with older servers) and ignore a negative value or treat it as 0.
10. Client: key the cache by method plus the params that affect the result, and MUST NOT serve a cached response for different method or params. Never cache the result of an MRTR retry that carried inputResponses or requestState.
11. Client: do NOT treat ttlMs as a polling interval. If you poll anyway, you MUST apply jitter and backoff.
12. Return tools from tools/list in a deterministic order — the same ordering across requests while the underlying tool set is unchanged — so clients can cache reliably and LLM prompt caches hit.
13. Pair the hints with listChanged notifications where available: a relevant notification invalidates a still-fresh cached response, making it immediately stale.
14. Verify: confirm hints are present on all six operations, that page 2 of a list carries the same cacheScope as page 1, and that a list_changed notification invalidates your client cache before ttlMs elapses.