Исправить передачу исходников в CI-контейнеры

docs/INFRASTRUCTURE.md

@@ -361,13 +361,19 @@ Deployment-файлов запрещено.
 
 Основные шаги:
 1. Backend unit/component tests, frontend static/unit tests, Compose validation, shell-тест
-   immutable rollout/rollback и регрессионная проверка закрепления артефактов.
+   immutable rollout/rollback и регрессионная проверка закрепления артефактов. Исходники
+   backend/frontend передаются тестовым контейнерам через `docker cp`: bind mount
+   `${{ github.workspace }}` не используется, потому что Docker daemon runner может
+   находиться вне job-контейнера и не видеть его файловую систему. Frontend security-тест
+   дополнительно получает backend в `/backend`, сохраняя ожидаемую соседнюю структуру.
 2. Только после успешных gates — login, параллельная сборка и push backend/frontend с
    SHA-tag и release tag без `latest`. Сторонние Actions закреплены полными commit SHA.
 3. BuildKit публикует для обоих образов максимальную provenance- и SBOM-attestation. Build
    jobs также возвращают registry digest каждого образа.
 4. Отдельный обязательный job сканирует опубликованные digests закреплённым Trivy `0.63.0` и
-   блокирует deploy при исправимых `HIGH`/`CRITICAL` уязвимостях.
+   блокирует deploy при исправимых `HIGH`/`CRITICAL` уязвимостях. Docker credentials для
+   приватного registry копируются во временный Trivy-контейнер через Docker API; bind mount
+   домашнего каталога job-контейнера не используется.
 5. Push в `main` выполняет проверки, сборку, публикацию и scan, но не меняет production.
    Deploy job запускается только вручную через `workflow_dispatch` и устанавливает
    фиксированный `kubectl v1.33.12` после SHA-256 проверки. Java Agent также имеет точную