cache: add graphql query response caching

docs/admin-api.md

@@ -141,9 +141,10 @@
 - `execution_config.response_cache` допускается только для:
   - `REST`
   - `GET`
+  - или `GraphQL query`
   - операций без `auth_profile_ref`
 - `execution_config.response_cache` не означает глобальный shared cache на все вызовы системы:
-  - response cache должен быть изолирован минимум по `workspace + agent + operation + request fingerprint`
+  - response cache должен быть изолирован минимум по `workspace + agent + operation + operation version + request fingerprint`
 - попытка создать, обновить или импортировать операцию с неподдерживаемым `protocol` или `security_level` должна завершаться `validation_error` еще на стороне `admin-api`, а не только скрываться в UI.
 
 ### 5.4. Samples and descriptors

docs/implementation-plan.md

@@ -184,7 +184,7 @@
 ### Цель
 
 Подготовить optional cache/coordination layer так, чтобы платформа могла использовать `Valkey/Redis`,
-но не зависела от него для базового запуска.
+но не зависела от него для базового запуска, и при этом закрыть первые коммерчески ценные cache hot paths.
 
 ### DoD
 
@@ -198,6 +198,10 @@
   - response cache по умолчанию изолировался по `workspace + agent + operation + operation version + request fingerprint`;
   - внешний cache backend можно было безопасно шарить между несколькими рабочими областями и агентами.
 - shared coordination cache уже применяется не только для rate limiting, но и для multi-instance snapshots published MCP catalogs.
+- response cache уже покрывает:
+  - `REST GET` как Community baseline;
+  - `GraphQL query` как первый коммерчески ценный read-only protocol path.
+- дальнейшее расширение response cache идет только по явно обоснованным read-only сценариям, начиная с `gRPC unary`, а не как общий cache для всех протоколов подряд.
 
 ## 14. Этап 11. Live staging and demo readiness
 

docs/mcp-interface.md

@@ -237,9 +237,9 @@ Crank должен корректно работать, если MCP client де
 - `POST` и `GET` transport semantics соответствуют MCP spec `2025-06-18`;
 - endpoint определяется парой `workspace + agent`;
 - одна published operation = один MCP tool внутри agent;
-- если операция явно включает `execution_config.response_cache`, первый поддержанный runtime path ограничен:
-  - `REST`
-  - `GET`
+- если операция явно включает `execution_config.response_cache`, текущий поддержанный runtime path ограничен:
+  - `REST GET`
+  - `GraphQL query`
   - без `auth_profile_ref`
   - cache keys изолируются минимум по `workspace + agent + operation + operation version + request fingerprint`
 - streaming operations публикуются как bounded tools или tool families;

docs/runtime-config.md

@@ -183,6 +183,14 @@ Demo/deployment:
 
 Второй контур хранит только кэшируемые ответы операций.
 
+Текущий безопасный runtime scope для response cache:
+
+- `REST GET`;
+- `GraphQL query`.
+
+Это не означает автоматическое кэширование всех protocol families. Следующим кандидатом на расширение
+может быть только явно read-only `gRPC unary`.
+
 Эти контуры не должны смешивать ключи друг с другом.
 
 ### Cache key isolation