[FIX] admin 회원 통계 응답이 실제 DB와 불일치 — social_type 대소문자 정규화

[minij02]

✨ 버그 설명

개발(dev) 환경에서 GET /api/admin/stats/members 응답의 total_members 및 채널별 카운트가 실제 DB 값과 불일치.

응답 (dev):

{ "total_members": 55, "email": 54, "google": 0, "kakao": 1, "naver": 0 }

DB 실측 (userstatus != 'deleted'):

NONE   : 54
KAKAO  : 1
google : 79   ← 소문자
naver  : 82   ← 소문자
--- total: 216

✨ 원인

src/stats/services/admin-stats.service.ts 의 SOCIAL_TYPE_TO_CHANNEL 매핑이 대문자 키만 정의:

{ NONE: 'email', GOOGLE: 'google', KAKAO: 'kakao', NAVER: 'naver' }

prisma.user.groupBy 결과에 소문자 google / naver 로우가 섞여 있어 매핑 실패 → if (!channel) continue; 로 인해 채널 카운트뿐 아니라 total 합산에서도 제외됨.

현재 코드는 소셜 로그인 시 모두 대문자로 저장 (config/social/*.ts, auth/services/auth.service.ts) 하므로 소문자는 레거시 데이터. dev DB 에만 잔존.

✨ 해결 방향

1. DB 백필: social_type 을 대문자로 정규화하는 prisma 마이그레이션 추가.
2. 서비스 방어: 매핑 lookup 시 toUpperCase() 로 case-insensitive 처리 (재발 방지, 한 줄).

✨ 개발 목록

• prisma 마이그레이션 추가 — UPDATE User SET social_type = UPPER(social_type) WHERE social_type IN ('google','naver','kakao')
• admin-stats.service.ts 매핑 lookup 정규화 (row.social_type?.toUpperCase())
• pnpm build 확인

✨ 기타

• 프로덕션 DB 도 동일 조건 쿼리로 사전 확인 후 반영 필요 (기존 정상이면 no-op).
• social_type 을 사용하는 다른 read 경로 (auth 응답 등) 는 값 그대로 노출하지만 비교 로직이 없어 영향 없음.