Adjust VM ApplicationSet for test env + per-URL tenant routing rationale

- applicationset: ns argocd→platform, repoURL service-catalog/tenant-catalog @master
- vmagent custom-values/CUSTOM-README: per-URL 채택 근거 정정(인라인 가능하나 보안·격리 위해 per-URL)
- architecture doc: §5.1 테넌트 라우팅 결정 기록 + monitoring 배포 테스트 문서

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

manifests/helm/victoria-metrics-agent/0.40.0/CUSTOM-README.md

@@ -30,7 +30,9 @@ helm upgrade vmagent ./ -f custom-values.yaml --install -n monitoring
 | 9000 | platform (kafka-system, kubeflow 등) | `/relabel/platform.yaml` |
 | 0 | fallback (미매칭) | 없음 |
 
-> 쓰기 경로는 vmauth를 경유하지 않고 vminsert(`:8480`)에 직접 쓴다. `writeRelabelConfigs`(camelCase)는 CLI 미지원이라 파일 마운트(`urlRelabelConfig`) 방식을 사용한다.
+> 쓰기 경로는 vmauth를 경유하지 않고 vminsert(`:8480`)에 직접 쓴다.
+>
+> **테넌트 라우팅 방식 결정 (per-URL)**: 차트는 `urlRelabelConfig`에 relabel 규칙을 **인라인**으로 줘도 자동으로 ConfigMap을 생성·마운트한다(기술적으로 인라인 가능). 그럼에도 **테넌트마다 별도 remoteWrite URL(`/insert/{accountID}/`) + 별도 relabel 파일**을 쓰는 이유는 **보안·격리** 때문이다: ① 테넌시를 URL이 강제하므로 데이터 라벨 스푸핑이 불가, ② 새 테넌트 추가가 Git/PR 변경(감사·승인)을 거침, ③ remoteWrite 큐가 테넌트별로 분리돼 장애·오설정의 cross-tenant 파급이 제한됨. (대안인 `/insert/multitenant/` + `vm_account_id` 라벨 매핑은 온보딩이 ConfigMap만으로 가능하나 테넌시가 relabel 규칙에 의존 → 격리가 약함. 트레이드오프는 아키텍처 문서 참조.)
 
 ### 2.2 scrape_configs
 

manifests/helm/victoria-metrics-agent/0.40.0/custom-values.yaml

@@ -7,6 +7,10 @@
 # accountID 매핑(예시): 0=플랫폼 공통(fallback) / 1=demo01 / 2=demo02 / 9000=platform
 #   네임스페이스별 분기는 urlRelabelConfig(ConfigMap: vmagent-relabel-configs) 마운트로 처리.
 #   해당 ConfigMap은 온보딩 시 별도 생성한다(CUSTOM-README 참조).
+#
+# 테넌트 라우팅 = per-URL 의도적 채택(보안·격리). 차트는 인라인 urlRelabelConfig도 지원하나,
+#   테넌시를 URL로 강제(스푸핑 차단)하고 테넌트 추가를 Git/PR로 통제하기 위해 per-tenant URL을 쓴다.
+#   → 새 테넌트 = remoteWrite 항목 추가(이 파일 수정) + relabel 파일 추가. 상세: CUSTOM-README / 아키텍처 문서.
 # =============================================================================
 
 # remoteWrite — 최소 1개 필요. accountID별 엔드포인트 + urlRelabelConfig 파일 분기