✨ Feature: 3D 명함 온디바이스 합성 파이프라인 — 텍스트 메시·사진 텍스처·파트 tint

[JEONG-J]

📌 작업 목적

3D 명함은 사용자마다 다른데 에셋은 템플릿 1종이다 — 런타임에 프로필 데이터를 템플릿에 바인딩하는 합성 파이프라인이 필요하다. 설계서 §6 이 정의한 온디바이스 방식이고, 현재 구현은 없다.

설계서 §6 파이프라인 4단계:

1. 베이스 씬 로드 — Entity(named: "BusinessCardTemplate", in: realityKitContentBundle)
2. 텍스트 메시 바인딩 — 이름/파트/기수 → MeshResource.generateText(...) 또는 미리 배치된 텍스트 앵커 교체
3. 사진 텍스처 바인딩 — 프로필 이미지 → TextureResource → 머티리얼 baseColor
4. 파트 악센트 컬러 — UMCPartType → 머티리얼 tint 룩업 테이블

서버 렌더를 쓰지 않기로 한 이유가 교환 페이로드에 직결된다 (§6): 수신 측이 같은 템플릿으로 재합성하므로 페이로드에 에셋 URL 을 싣지 않는다. 즉 ExchangePayload.usdzURL(UMCApp/Core/NearbyExchange/Sources/Models/ExchangePayload.swift:35) 이 비어 있는 것은 설계상 정상이며, 합성이 이 결정을 성립시킨다.

같은 파이프라인이 두 주체를 그린다:

• 내 명함 — MyCard 로 합성
• 받은 명함 — ReceivedCard 의 프로필 필드로 합성 (수신 측 재합성)

✅ 완료 조건

• 베이스 템플릿 로드 + 엔티티 준비 (에셋 규약 이슈의 앵커·슬롯 이름 사용)
• 이름·파트·기수 텍스트 바인딩 — 한글 렌더 품질 확인
• 긴 이름·영문 이름 대응 (말줄임 또는 크기 조정 — 규칙 확정 후 구현)
• 프로필 사진 텍스처 바인딩 + 이미지 없을 때 폴백
• 파트 악센트 tint 룩업 — 미정의 파트가 들어와도 깨지지 않게 폴백 색 지정
• MyCard · ReceivedCard 양쪽에서 같은 파이프라인 사용
• 합성 실패 시 에러 전달 (조용히 빈 카드를 만들지 않을 것)
• 텍스처·엔티티 메모리 해제 확인 (명함 여러 장 오갈 때 누수 없음)
• 합성 결과 검증 테스트 — 프로필 필드가 실제로 바인딩됐는지

🔗 관련 정보

• 설계서 §6 · §8
• 선행: Phase 0 기술 검증, 베이스 USDZ 템플릿 에셋