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/ci-gate-matrix.yml

@@ -487,6 +487,82 @@ gates:
     job: documentation-contracts
     execution: job
   #
+  # The six Docker-backed MongoDB lanes. Registered in the leaf, excluded from `test` by tag, absent
+  # from `check`, and named by no workflow until now — scripts/verify-mongodb-platform.sh was the
+  # only caller and nothing in .github runs it. One row per lane because each is its own single-line
+  # command, which is what makes `execution: explicit` checkable.
+  #
+  # release_blocking: false is the honest value, not a demotion: stage 2 runs after the merge, so no
+  # release gate can wait on it. Promoting these to stage 1 would put a replica set, a three-node
+  # failover and a Toxiproxy on the pull-request budget.
+  - id: mongo-replica-set-lane
+    release_blocking: false
+    mechanism: gradle-custom-task
+    ref: mongoReplicaSetTest
+    workflow: integration-main.yml
+    job: mongo-container-lanes
+    execution: explicit
+  - id: mongo-failover-lane
+    release_blocking: false
+    mechanism: gradle-custom-task
+    ref: mongoFailoverTest
+    workflow: integration-main.yml
+    job: mongo-container-lanes
+    execution: explicit
+  - id: mongo-migration-lane
+    release_blocking: false
+    mechanism: gradle-custom-task
+    ref: mongoMigrationTest
+    workflow: integration-main.yml
+    job: mongo-container-lanes
+    execution: explicit
+  - id: mongo-compatibility-lane
+    release_blocking: false
+    mechanism: gradle-custom-task
+    ref: mongoCompatibilityTest
+    workflow: integration-main.yml
+    job: mongo-container-lanes
+    execution: explicit
+  - id: mongo-security-integration-lane
+    release_blocking: false
+    mechanism: gradle-custom-task
+    ref: mongoSecurityIntegrationTest
+    workflow: integration-main.yml
+    job: mongo-container-lanes
+    execution: explicit
+  - id: mongo-performance-lane
+    release_blocking: false
+    mechanism: gradle-custom-task
+    ref: mongoPerformanceTest
+    workflow: integration-main.yml
+    job: mongo-container-lanes
+    execution: explicit
+  #
+  # The messaging contract evidence DAG. One row, because one job is one control and the control is
+  # the aggregate: `verifyMessagingContracts` reaches five strict qualification tasks, and through
+  # them `prepareMessagingContractEvidence`, plus both manifest schema validators
+  # (validateMessagingJsonSchemaV1EvidenceManifestSchema by dependsOn,
+  # validateMessagingContractsEvidenceManifestSchema by finalizedBy). Strict qualification tasks are
+  # registered outside `check` by design, so before this job none of the seven executed anywhere.
+  - id: messaging-contract-evidence
+    release_blocking: false
+    mechanism: gradle-custom-task
+    ref: verifyMessagingContracts
+    workflow: integration-main.yml
+    job: messaging-contract-evidence
+    execution: explicit
+  #
+  # app-bootstrap's Testcontainers lane. Its own source set exists so that `:app-bootstrap:test`
+  # needs no Docker daemon; the unclosed consequence was that a source set outside `test` is also
+  # outside `check`, so these contracts compiled everywhere and ran nowhere.
+  - id: bootstrap-integration-contracts
+    release_blocking: false
+    mechanism: gradle-custom-task
+    ref: integrationTest
+    workflow: integration-main.yml
+    job: bootstrap-integration
+    execution: explicit
+  #
   # notification-platform.yml — `pr` is path-filtered and also runs on push to main; nightly-chaos
   # is schedule/dispatch only. The release-blocking notification controls are the verifyNotification*
   # rows above, which run inside check on every pull request.
@@ -768,7 +844,7 @@ gates:
     job: httpclient-release-gate
     execution: explicit
   #
-  # Tag-triggered (`v*`, `web-v*`). The Stable web release gate.
+  # Tag-triggered (`v*`). The Stable web release gate.
   - id: web-stable-release-gate
     release_blocking: true
     mechanism: workflow-job
@@ -777,7 +853,7 @@ gates:
     job: web-stable-release-gate
     execution: job
   #
-  # Tag-triggered (`v*`, `websocket-v*`). The Stable websocket release gate.
+  # Tag-triggered (`v*`). The Stable websocket release gate.
   - id: websocket-stable-release-gate
     release_blocking: true
     mechanism: workflow-job
@@ -786,6 +862,36 @@ gates:
     job: websocket-stable-release-gate
     execution: job
   #
+  # Tag-triggered (`v*`). The three gRPC certification lanes, one row each because each runs as its
+  # own single-line command and `execution: explicit` is only verifiable that way.
+  #
+  # These were registered lanes that no workflow named. Their tests are not new coverage — the
+  # `grpc-inprocess`, `grpc-netty` and `grpc-fault` tags run inside `:grpc:grpc-testkit:test`, which
+  # is inside `check` — so what the lanes add is the fail-on-nothing-discovered guard that a tag
+  # filter inside `test` cannot give you. Same argument as web-advanced and websocket-advanced above,
+  # and the same placement.
+  - id: grpc-inprocess-contract-lane
+    release_blocking: true
+    mechanism: gradle-custom-task
+    ref: grpcInProcessContractTest
+    workflow: release.yml
+    job: grpc-stable-release-gate
+    execution: explicit
+  - id: grpc-netty-transport-lane
+    release_blocking: true
+    mechanism: gradle-custom-task
+    ref: grpcNettyContractTest
+    workflow: release.yml
+    job: grpc-stable-release-gate
+    execution: explicit
+  - id: grpc-fault-lane
+    release_blocking: true
+    mechanism: gradle-custom-task
+    ref: grpcFaultTest
+    workflow: release.yml
+    job: grpc-stable-release-gate
+    execution: explicit
+  #
   # Tag-triggered (`v*`). The only job in this repository that produces a deployable artifact.
   #
   # One row, not three, because one job is one control: the job builds the app-bootstrap image,