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>

doc/victoria-metrics-architecture.md

@@ -128,6 +128,24 @@ flowchart TB
 
 > **비대칭**: 메트릭은 `/select/multitenant/`로 전체 테넌트 집계가 가능하나, VictoriaLogs는 합산 엔드포인트가 없어 `(AccountID, ProjectID)` 단위로만 조회된다.
 
+### 5.1 메트릭 쓰기 경로 테넌트 라우팅 결정 (per-URL)
+
+위 표는 **조회(read)** 경로다. **쓰기(write)** 경로에서 vmagent가 테넌트를 어떻게 가르는지는 두 가지 선택지가 있고, **per-URL을 채택**한다.
+
+| 방식 | 동작 | 온보딩 | 격리 |
+|------|------|--------|------|
+| **per-URL (채택)** | 테넌트마다 별도 remoteWrite `/insert/{accountID}/` + `urlRelabelConfig` keep 필터 | 새 테넌트 = vmagent 값 + relabel 수정 → **Git/PR** | **강** — URL이 테넌시 강제 |
+| multitenant+라벨 (대안) | 단일 `/insert/multitenant/` + relabel로 `vm_account_id` 라벨 set | ConfigMap만 수정 | 약 — 라벨(=relabel 규칙)에 의존 |
+
+**per-URL 채택 근거 (보안·격리 우선)**
+- **스푸핑 차단**: 테넌시가 URL로 고정 → 스크레이프 대상이 `vm_account_id` 라벨을 노출해도 테넌트 위장 불가.
+- **변경 통제**: 새 테넌트(=새 accountID) 추가가 Git/PR 리뷰·승인을 거침(ConfigMap 한 줄 수정보다 통제 강함).
+- **장애·오설정 격리**: remoteWrite 큐가 테넌트별로 분리 → 한 테넌트 문제나 relabel 오타의 cross-tenant 파급 제한.
+
+**트레이드오프(감수)**: 새 테넌트 추가 시 vmagent 값(remoteWrite)도 함께 수정·재배포해야 한다. (multitenant+라벨은 ConfigMap만으로 온보딩되지만 테넌시가 relabel 규칙에 의존해 격리가 약함 — 채택 안 함.)
+
+> 같은 테넌트의 새 네임스페이스(`demo01-*`)는 prefix 정규식이 커버하므로 **무변경**. 변경이 필요한 건 **새 accountID(테넌트) 추가** 시뿐이다. 차트는 인라인 `urlRelabelConfig`도 지원하나, 위 근거로 per-tenant URL + 별도 relabel ConfigMap을 쓴다.
+
 ## 6. 인증/인가 (Keycloak `paasup` realm)
 
 ```mermaid