feat(mcp): wire ResponseCachingMiddleware for read tools (5m TTL)

[dougborg]

Problem

Agents that work in Front via the MCP server repeatedly fetch the same discovery data within a single session — teammates, channels, inboxes, tags, custom fields. Each call hits Front's API. We can cut latency and API call volume by caching read responses at the MCP boundary.

Solution

Wire fastmcp's built-in ResponseCachingMiddleware after the fastmcp 3.x bump (see #108). Stocktrim landed this as PR #158.

Configuration:

• Tools: 5-minute TTL
• Resources: 60-second TTL (less likely to be re-fetched as often, lower TTL keeps freshness)
• Exclude mutation tools by name pattern: create_*, update_*, delete_*, archive_*, move_*, assign_*, unassign_*, tag_*, untag_*, mark_*

Depends on

• chore(mcp): migrate fastmcp 2.x → 3.x (precondition for caching middleware, prompts, prefab UI) #108 (fastmcp 3.x migration)

Files to change

• frontapp_mcp_server/src/frontapp_mcp/server.py — register middleware
• A new frontapp_mcp_server/src/frontapp_mcp/middleware/cache.py if any custom predicate is needed for the exclusion pattern
• frontapp_mcp_server/docs/ — short doc page on cache behavior + how operators can swap to Redis (per stocktrim's observability.md precedent)

Acceptance criteria

• Mutation tools are NOT cached (verified via test or middleware log)
• Read tools return cached results on repeat calls within TTL
• Cache TTL is configurable via env var (FRONTAPP_MCP_CACHE_TTL_TOOLS, _RESOURCES)
• Manual smoke: call list_teammates twice in a row, second is observably faster

Reference

• feat(mcp): adopt ResponseCachingMiddleware for read-heavy tools and resources stocktrim-openapi-client#158