docs: add references for 64kb investigation

doc/decisions/message-size-limit-2026-04-11.md

@@ -101,3 +101,24 @@ POST status=408 req_len=49926 bytes_sent=0 time=10.001s
 
 1. Для повседневного использования через AWS CLI/botocore ориентироваться на payload до 32KB.
 2. Если в будущем потребуется надёжная поддержка 64KB+ для этих клиентов, исправление нужно делать в platform ingress layer, а не в shared-sqs.
+
+## Ссылки для повторного разбора
+
+- Штурвал Community Edition, архитектура платформы:
+	https://docs.k8s.ngcloud.ru/2.12/docs/common/structure/
+
+- ingress-nginx annotations:
+	https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/
+
+- ingress-nginx configmap:
+	https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/
+
+- upstream parser `proxy-request-buffering`:
+	https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/annotations/proxy/main.go
+
+- upstream e2e tests for proxy annotations:
+	https://github.com/kubernetes/ingress-nginx/blob/main/test/e2e/annotations/proxy.go
+
+Если к вопросу 64KB+ возвращаться позже, эти ссылки нужны для быстрого подтверждения двух вещей:
+- ingress controller у нас platform-managed со стороны Штурвала;
+- аннотация `proxy-request-buffering` в upstream ingress-nginx поддерживается официально.

doc/errors/65kb-payload-timeout-2026-04-11.md

@@ -110,3 +110,26 @@ POST status=408 req_len=49926 bytes_sent=0 time=10.001s
 
 ## Статус
 ✅ Исследование завершено. Root cause локализован до platform ingress layer; изменение в коде shared-sqs не требуется.
+
+## Внешние ссылки
+
+Для следующего захода в проблему использовать эти ссылки как стартовые:
+
+- Штурвал Community Edition, архитектура платформы:
+  https://docs.k8s.ngcloud.ru/2.12/docs/common/structure/
+
+- ingress-nginx annotations:
+  https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/
+
+- ingress-nginx configmap options:
+  https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/
+
+- parser `proxy-request-buffering` в upstream ingress-nginx:
+  https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/annotations/proxy/main.go
+
+- e2e test `should turn off proxy-request-buffering`:
+  https://github.com/kubernetes/ingress-nginx/blob/main/test/e2e/annotations/proxy.go
+
+Краткий смысл ссылок:
+- Штурвал: подтверждает, что Nginx Ingress Controller является частью platform stack;
+- ingress-nginx docs/source: подтверждают, что `proxy-request-buffering` — штатная поддерживаемая фича upstream, а значит текущее поведение похоже именно на platform-specific limitation/bug.

doc/progress.md

@@ -39,6 +39,7 @@
 - upstream ingress-nginx эту аннотацию поддерживает, значит это platform-specific limitation/bug;
 - hard-limit 32KB в код shared-sqs НЕ вводим;
 - 32KB остаётся практической рекомендацией для AWS CLI / botocore в текущей инфраструктуре.
+- внешние ссылки для повторного разбора сохранены в `doc/thinking/2026-04-12.md`, `doc/errors/65kb-payload-timeout-2026-04-11.md` и `doc/decisions/message-size-limit-2026-04-11.md`.
 
 ### v0.1.19 (2026-04-11) ✅ — ПРЕДЫДУЩАЯ DEPLOYED
 - ✅ Валидация VisibilityTimeout (0–43200) в ReceiveMessage

doc/thinking/2026-04-12.md

@@ -237,3 +237,52 @@
 ## Короткий финальный вывод одним абзацем
 
 Проблема 64KB+ payload у shared-sqs оказалась не багом Go-сервиса и не проблемой Redis/persistence, а ограничением ingress path в кластере штурвала: объект ingress у приложения настроен корректно, часть аннотаций применяется, но именно `proxy-request-buffering` platform controller в итоговый nginx.conf не прокидывает, при этом upstream ingress-nginx такую аннотацию поддерживает. Поэтому вводить hard-limit 32KB в коде я считаю неправильным; правильное практическое решение на текущий момент — оставить сервис без искусственного code-level ограничения, а 32KB считать безопасным эксплуатационным размером и документировать это как известную особенность инфраструктуры.
+
+---
+
+## Внешние ссылки для возврата к теме 64KB+
+
+Если к проблеме придётся вернуться через недели или месяцы, начинать смотреть отсюда.
+
+### Платформа Штурвал
+
+- Архитектура платформы Штурвал Community Edition:
+   https://docs.k8s.ngcloud.ru/2.12/docs/common/structure/
+
+Зачем это важно:
+- страница подтверждает, что Nginx Ingress Controller входит в состав платформы;
+- это усиливает вывод, что ingress controller для `qu.kube5s.ru` является platform-managed компонентом, а не частью shared-sqs.
+
+### Официальная документация ingress-nginx
+
+- Аннотации ingress-nginx:
+   https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/
+
+- ConfigMap ingress-nginx:
+   https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/
+
+Ключевые места в этих документах:
+- `nginx.ingress.kubernetes.io/proxy-request-buffering` официально поддерживается;
+- `allow-snippet-annotations` по умолчанию имеет значение `false`;
+- `server-snippet` и `configuration-snippet` нельзя считать доступным workaround без platform-level разрешения.
+
+### Upstream исходники ingress-nginx
+
+- parser аннотации `proxy-request-buffering`:
+   https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/annotations/proxy/main.go
+
+- e2e-тест на `should turn off proxy-request-buffering`:
+   https://github.com/kubernetes/ingress-nginx/blob/main/test/e2e/annotations/proxy.go
+
+Зачем это важно:
+- это прямое подтверждение, что в upstream поведение поддерживается и ожидается;
+- если проблема повторится, не надо заново спорить, существует ли такая аннотация вообще.
+
+### Что проверить первым делом при новом раунде расследования
+
+1. Существует ли по-прежнему только один ingress для `qu.kube5s.ru`.
+2. Осталась ли аннотация `proxy-request-buffering: "off"` на объекте ingress.
+3. Что реально сгенерировано в `/etc/nginx/nginx.conf` у ingress controller.
+4. Не изменились ли версия штурвала и версия ingress-nginx controller.
+5. Не включили ли на platform уровне `allow-snippet-annotations`.
+6. Не появился ли доступ к source-of-truth конфигурации платформенного ingress controller.