자체 빌드 Go 이미지 3종의 툴체인을 1.26.6 으로 올린다 (#35) (#36)

etcd·cloudnative-pg·apisix-ingress-controller 가 GO_BUILDER_TAG=1.26.5-trixie 에 핀돼
있어 새로 공개된 stdlib 차단 CVE 8건에 걸린다. 전부 Go 1.26.6 에서 고쳐졌다.

소스는 하나도 안 바꿨다 — CVE 데이터가 갱신됐을 뿐이다. 자체 빌드 이미지는 이렇게
가만히 있어도 게이트를 벗어난다는 것이 이번 사례의 요지다.

발견 경위
--------
PR #34(문서 전용)가 images/** 를 건드려 검증 빌드가 돌면서 드러났다. 오늘 날짜로
재빌드하니 etcd·cloudnative-pg 가 각각 실효 0/8 로 FAIL 했고, 기능 검증(verify.sh)은
둘 다 VERIFY-OK 였다 — 게이트만 실패했다. 대조군으로 어제 1.26.6 으로 올린 argocd 는
같은 실행에서 PASS 했다.

값은 손으로 고르지 않았다
------------------------
  python3 scripts/build/suggest-go-upgrades.py --reports <trivy-reports>
  → GO_BUILDER_TAG=1.26.6-trixie / 모듈 업그레이드 제안 없음(stdlib 전용)

FixedVersion 의 `1.25.13, 1.26.6, 1.27.0-rc.3` 은 브랜치별 대안이라 최대값을 고르면
프리릴리스를 정식 버전으로 오독한다. 스크립트가 그 규칙을 처리한다.

apisix-ingress-controller 는 이번 검증 빌드 대상이 아니었다
--------------------------------------------------------
PR #34 가 이 이미지 파일을 건드리지 않아 매트릭스에서 빠졌을 뿐, 같은 툴체인 핀이다.
trivy 는 바이너리에 박힌 Go 버전으로 stdlib 을 판정하므로 1.26.5 로 빌드한 Go 바이너리는
예외 없이 해당된다. 이 PR 의 검증 빌드가 셋 다 돌려 확인한다.

각 build.env 주석에 "이 값은 go.mod 최소 요구가 아니라 stdlib 차단 CVE 를 해소하는
지점으로 정한다" 를 적어뒀다 — 다음 사람이 go.mod 만 보고 되돌리지 않게 하기 위함이다.

Refs #35

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

images/etcd/source.build.env

@@ -22,7 +22,11 @@ SOURCE_COMMIT=5e7fd0de9a57db03ecc11794dc40403a734c07bb
 
 # go.mod 의 `go 1.26`/`toolchain go1.26.5` 요구를 만족하는 공식 golang 이미지 태그.
 # 이 이미지는 builder 스테이지에서만 쓰이고 최종 이미지에는 남지 않는다.
-GO_BUILDER_TAG=1.26.5-trixie
+#
+# 값은 go.mod 최소 요구가 아니라 **stdlib 차단 CVE 를 해소하는 지점**으로 정한다 — 소스를
+# 안 바꿔도 CVE 데이터가 갱신되면 여기가 올라간다. 손으로 고르지 않는다:
+#   python3 scripts/build/suggest-go-upgrades.py --reports <trivy-reports> --image etcd
+GO_BUILDER_TAG=1.26.6-trixie
 
 # 최종 런타임 베이스 — 카탈로그는 SUSE BCI 하나만 쓴다(decisions/0001). 정적 링크
 # 바이너리(CGO_ENABLED=0)라 패키지 매니저가 없는 가장 가벼운 bci-micro 로 충분하다.