fix(build,ci): 정의만 되고 안 돌던 레인 13개를 배선하고 버전 11개를 카탈로그로

감사 remediation 의 마지막 항목 두 개.

## 아무 데서도 안 돌던 레인

등록 태스크 97개 중 어느 CI 경로로도 도달하지 않는 것이 20개였다.
있는 줄 알았는데 안 도는 상태 — 이번에 고친 `*CleanArchitectureTest` 와 같은
종류의 문제다. 각각 판단해서 처리했고, 삭제는 0건이다.

- stage 2(`integration-main.yml`, push:main + 03:00) 에 잡 3개 신설:
  mongo 컨테이너 레인 6개 / messaging 계약 증거 3개 / app-bootstrap integrationTest.
  컨테이너가 필요한 레인은 PR 에 두지 않는다 — PR 예산은 5분이고, 단계를 나눈
  이유가 이것이다
- stage 3(`release.yml`) 에 `grpc-stable-release-gate` 신설
  (inprocess/netty/fault) + `app-image-release` 의 needs 로 연결
- 수동 확정 3개: `grpcPerformanceTest`, `openapiCheckSnapshot`(드리프트 검사는
  이미 stage 1 의 `check` 안에 있고 이 태스크는 승인 지점),
  `sampleOffCompile`(stage 1 `sampleOffTest` 의 진부분집합).
  전용 레지스트리 대신 루트 README 에 적었다 — `verifyReadmeCommands` 가
  거기 적힌 태스크의 실재를 검증하므로, 문서가 곧 검사 대상이 된다
- 게이트 매트릭스 행 11개 신설. 잡↔행 양방향 대조 결과 68개 잡 전부 행이 있고
  행 없는 잡도, 어디서도 안 도는 잡도 없다

측정이 틀린 4건은 배선하지 않았다 — 이미 도달하고 있었다:
`jpaPlatformReleaseGate`(`jpaReleaseGate dependsOn`),
`generateJpaEvidenceManifests`(`verifyJpaCandidateEvidence` 경유),
`messagingCertificationTest`(`verifyMessagingCertificationEvidence` 경유),
`stageDockerJar`(호출자가 Gradle 이 아니라 `release.yml` 의 `docker build`).

## 버전 카탈로그 이관

카탈로그를 우회해 문자열로 박혀 있던 값 11개를 `gradle/libs.versions.toml` 로
옮겼다. plugin 5개는 `[plugins]` + `alias(...)`, 툴 3개는 `libs.versions.*.get()`.

`grpcVersion`/`protobufVersion`/`awsSdkVersion` 은 이관이 불가하다고 넘어온
항목이었으나, `ext.x` 를 접근자로 남기고 값만 카탈로그에서 읽으면 소비 파일 9개와
`ca.grpc-platform-module.gradle:28` 의 `findProperty` 계약이 그대로이고 해석
결과도 동일하다. **lockfile 재생성 0건.**

`commons-lang3` / `netty` 는 BOM 오버라이드라 그대로 둔다 — 오버라이드하는
이유가 주석과 분리되면 값만 남고 근거가 사라진다.

## 검증 (깨끗한 체크아웃, 커밋 전)

`verify-gate-matrix.sh` → 107 gates, 101 verified, drift 0 ·
`verify-gradle-wrapper.sh` PASS · 워크플로 YAML 21개 파싱 OK ·
`gradlew help` · `verifyCleanArchitectureDependencies` · `build-logic test` ·
`:app-bootstrap:test` **1001 tests 실패 0** · `:domain-core:check` ·
`verifyDocumentationContracts` · `verifyDependencyLocks` · `verifyReadmeCommands`.

## 남은 문제

mongo 6레인 · `bootstrap-integration` · messaging 매니페스트 스키마 검증은
CI 에서 한 번도 돈 적이 없다. Docker 가 없으면 실패하도록 설계돼 있으므로
**첫 main push 와 03:00 run 이 빨간 것이 정상 시나리오**다. 로컬에서 Docker
레인을 돌려보지 않았고, `mongo-container-lanes` 의 timeout 90분은 실측이 아니라
추정치다.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.github/scripts/verify-gradle-wrapper.sh

@@ -34,7 +34,7 @@ readonly EXPECTED_WORKFLOW_LOCK=(
   '2fa9c8081df1679c1feb9aa101aff47d7d2c24995c155aff6d1e4799eaad8f21  .github/workflows/fileserver-nightly.yml'
   '1686b7b637611c8cd5eb87b2cc759f5cd2c6b878154363fc336c16b93c635ada  .github/workflows/fileserver-pr.yml'
   'b47932200c9ac9db57070b43bc70c40c89c152e9235d7a1325baab407df215e9  .github/workflows/fileserver-release.yml'
-  '3dc5a3e989043725133a1bbc90636c261406fafaf0158672323ae29dda95c5dd  .github/workflows/integration-main.yml'
+  'a18a0f08982b393177a843c1bdd03a881d9d12491819cebb44b6891a87ff2a6d  .github/workflows/integration-main.yml'
   '4345d5cfb5a139a11cf3647c58fff61ab08397ace186919cdc7a769cdfc4d4b7  .github/workflows/jpa-next-hibernate8.yml'
   '726b3d91603a2529205d1d5568253b57d85fcbb9d10d3efe182491c9da744d78  .github/workflows/jpa-next-jpa4.yml'
   '3c073a928dfb266051a1a52f4d66bf6d6903b9dbd2cdb6459fab661228f27e88  .github/workflows/jpa-next-postgresql19.yml'
@@ -47,7 +47,7 @@ readonly EXPECTED_WORKFLOW_LOCK=(
   'e685bc846108503ee2cf1e06b6cec040174d49348bd205400f891828f24dda68  .github/workflows/object-storage-qualification.yml'
   '67ef53adb80551629a482e2610a0753dd0fadf85f523e985c4693354df543748  .github/workflows/pr-adapters.yml'
   '376a71f7a2b9990e1e96937ad3dd46a33f266cc742ca499b208bc909897b67f3  .github/workflows/redis-sdk-topology.yml'
-  '3f1ff34053bb455587ab9f03305331310b4df4aa4a49bddf875b6969c9afaa05  .github/workflows/release.yml'
+  '42b57385c1f87170ba6d882345c709c11dff019f1860e72ad989b0c5c1a67ece  .github/workflows/release.yml'
 )
 readonly EXPECTED_COMPOSITE_ACTION_LOCK=(
   '7ec6591f26a1bd76658c55472e16b195b80db2c4792b429efda5a0dcbde61a45  .github/actions/setup-gradle-java/action.yml'