[chore] 썸네일 처리 용량 실측 및 thumbnail.executor 설정값 확정

[hamtorygoals]

📄 Description

#86에서 분리된 후속 작업입니다. #86에서는 thumbnailExecutor 큐 초과(RejectedExecutionException) 시 업로드 응답이 500으로 깨지는 정합성 버그를 PhotoUploadService와 PhotoSweepScheduler 양쪽에 수정했습니다. 이 이슈는 그 수정 이후 남은, 실제 인프라에서의 실측이 필요한 용량 튜닝 작업을 다룹니다.

#86 원본 조사에 따르면, Object Storage 지연 80ms를 흉내 낸 환경에서 동시 사용자 3명이 각자 20개 배치를 완료 등록했을 때 완료 직후 thumbnailExecutor 활성 스레드 4, 대기 큐 56/100까지 찼습니다. 사용자 56명만 겹쳐도(56 × 20 = 100~120) 큐가 가득 차는 시나리오가 드문 예외가 아니라 흔한 정상 케이스일 수 있습니다.

✅ Tasks

• [fix] 썸네일 큐 초과 시 성공한 업로드가 500으로 응답될 위험 #86 수정 이후, 동시 사용자 6~10명 × 20개 배치 등 현실적인 부하로 재측정해 큐가 실제로 어느 시점에 얼마나 차는지, 그 상태에서 썸네일 준비 지연이 체감상 허용 가능한지 확인
• 측정 근거로 thumbnail.executor.queue-capacity(및 필요 시 core/max-pool-size)를 application.yaml에 명시적으로 설정하고 근거를 의사결정 로그에 기록

📎 ETC

• 대기 중인 큐 항목은 이미지 바이트가 아니라 photoId(UUID) 참조만 들고 있어 큐 용량 자체를 늘리는 메모리 비용은 크지 않음.
• 재배포 시 큐에 남은 작업은 유실되고 스윕이 나중에 복구하는 구조라(docs/architecture/backend-architecture.md 4.3), 큐를 넉넉히 잡아도 치명적이진 않으나 유실 폭이 커지는 트레이드오프는 있음.
• [fix] 썸네일 큐 초과 시 성공한 업로드가 500으로 응답될 위험 #86 수정으로 큐 초과 시 응답/스윕 모두 안전하게 처리되므로, 이 작업은 정합성 버그가 아니라 순수 용량/성능 튜닝입니다.