apisix의 keycloak-authz 커스텀 태그를 published.json 표준 경로 예외로 반영한다

apisix에 얹는 keycloak-authz 커스텀 플러그인 오버레이는 hardened-containers
표준 파이프라인 밖에서 별도로 빌드돼 같은 리포지토리에 -keycloak-authz 접미사를
붙여 추가로 push된다. published.json에는 이 접미사 태그가 절대 안 잡혀서,
apply-published-tags.py가 무필터로 ref를 그대로 적용하는 지금 방식으로는
카탈로그가 순정(keycloak-authz 없는) 태그를 가리키게 되는 실질적 회귀가 있었다
(manifests/helm/apisix/2.17.0/custom-values.yaml이 실제로 이 상태였다).

scripts/build/resolve-apisix-keycloak-authz-tag.py를 새로 만들어
apply-published-tags.py가 읽기 전에 published.json 사본의 apisix 항목을
제자리에서 고쳐 쓴다 — base 태그에 -keycloak-authz 버전이 실제로 있으면 그걸로
교체하고, 없으면 apisix 항목 자체를 지워 표준 "없다" 분기가 자연히 건너뛰게
한다(순정 태그로 되돌리는 일은 없다). apply-published-tags.py는 한 줄도
안 건드렸다.

catalog-tag-update.yml에 이 전처리를 한 스텝만 끼워 넣고, 즉시 1회 실행해
2.17.0의 회귀를 이 커밋에서 바로 고쳤다(3.18.0-security-hardened-20260826 →
...-keycloak-authz).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

catalog/image-map/README.md

@@ -34,3 +34,20 @@ hardened-containers 가 알아야 하므로, 레포 분리 시 이 지식을 카
 여러 버전을 **의도적으로 병행 추적**해야 하는 예외적 케이스(같은 이미지를 쓰는 두
 메이저 라인을 동시에 지원해야 하는 경우 등)만 공백으로 여러 디렉토리를 나열한다 —
 이 경우 왜 병행이 필요한지 `CUSTOM-README.md`나 커밋 메시지에 근거를 남긴다.
+
+## 발행 경로가 published.json 하나로 안 끝나는 이미지
+
+원칙은 "`published.json`의 `ref`를 그대로 믿고 반영한다"지만, 일부 이미지는
+hardened-containers의 표준 파이프라인 밖에서 만들어져 `published.json`에 안
+잡힌다. 현재 유일한 사례: **apisix의 keycloak-authz 커스텀 플러그인 오버레이**
+— 표준 빌드 뒤에 별도 프로세스가 같은 리포지토리에 `-keycloak-authz` 접미사를
+붙여 추가로 push한다.
+
+이런 이미지는 `published.json`을 그대로 신뢰하지 않고, `catalog-tag-update.yml`이
+그 이미지 전용 전처리 스크립트로 published.json 사본을 먼저 고쳐 쓴 뒤에야 표준
+반영 로직(`apply-published-tags.py`)이 돈다 — apisix의 경우
+`scripts/build/resolve-apisix-keycloak-authz-tag.py`. **원하는 태그가 실제로
+존재할 때만 대체하고, 없으면 그 이미지를 이번 실행에서 건너뛴다** — 접미사 없는
+순정 태그로 되돌리는 일은 없다(순정으로 돌아가면 그 이미지가 실제로 요구하는
+커스텀 기능이 빠지는 회귀가 된다). 다음에 비슷한 예외가 생기면 이 패턴을
+참고한다.