cache: scope response entries by operation version

docs/implementation-plan.md

@@ -195,7 +195,7 @@
 - Enterprise может подключать свой `Valkey/Redis` на уровне single-node или cluster deployment.
 - cache namespaces документированы так, чтобы:
   - platform / coordination state не смешивался с response cache;
-  - response cache по умолчанию изолировался по `workspace + agent + operation + request fingerprint`;
+  - response cache по умолчанию изолировался по `workspace + agent + operation + operation version + request fingerprint`;
   - внешний cache backend можно было безопасно шарить между несколькими рабочими областями и агентами.
 - shared coordination cache уже применяется не только для rate limiting, но и для multi-instance snapshots published MCP catalogs.
 

docs/mcp-interface.md

@@ -241,7 +241,7 @@ Crank должен корректно работать, если MCP client де
   - `REST`
   - `GET`
   - без `auth_profile_ref`
-  - cache keys изолируются минимум по `workspace + agent + operation + request fingerprint`
+  - cache keys изолируются минимум по `workspace + agent + operation + operation version + request fingerprint`
 - streaming operations публикуются как bounded tools или tool families;
 - reload published tools без пересборки сервиса;
 - никакой draft-логики или admin CRUD в MCP слое.

docs/runtime-config.md

@@ -195,7 +195,7 @@ Demo/deployment:
 
 Стартовая модель namespace для response cache:
 
-- `workspace + agent + operation + request fingerprint`
+- `workspace + agent + operation + operation version + request fingerprint`
 
 Стартовая модель namespace для platform / coordination cache: