fix(mindrecord): 수신자 데일리질문 isDraft 를 파싱하지 않고 false 하드코딩 — draft 노출 방어가 무효 #956

📜 Overview (Required)

수신자용 데일리질문 매퍼가 isDraft 를 파싱하지 않고 false 리터럴로 하드코딩한다 (MindRecordMapper.kt:18-19, 주석: "데일리질문 수신자 응답은 isDraft 미노출 — 서버가 draft 를 전달 대상에서 제외한다고 가정").

그런데 ReceiverMindRecordViewModel 은 "서버가 제외하기를 기대하나 방어적으로 한 번 더 거른다"며 두 목록 모두에 filterNot { it.isDraft } 를 건다 — 데일리질문 쪽은 항상 false 라 통과율 100% 인 무효 필터다. BE 가 draft 제외를 빠뜨리면(또는 이미 안 하고 있다면) 작성자가 임시저장만 해 둔 답변이 수신자에게 그대로 노출된다. 일기 쪽(ReceiverDiaryItemDto.isDraft 파싱)은 정상 동작하므로 두 목록의 방어 수준이 갈려 있다.

주석의 전제가 Swagger 로 반증된다 — 실측(2026-08-23, dev /v3/api-docs) 기준 GET /receiver-auth/daily-question 응답 항목은 발신자 목록과 같은 DailyQuestionListResponse 스키마를 재사용하며 isDraft 를 포함한다([userDailyQuestionId, title, content, createdAt, isDraft, receivers]). 즉 계약에 있는 값을 FE 가 버리고 있는 것이라, ReceiverDailyQuestionItemDto 에 isDraft 파싱을 추가하면 기존 필터가 그대로 실효화된다.

📌 Child Issue(Optional)

No response

📍 Note (Optional)

• PR refactor(mindrecord): DTO 기본값·불필요 nullable 제거 — 누락 계약을 정상값으로 은폐하지 않는다 #933 리뷰 중 발견 (리뷰 "이 PR 밖" 섹션). refactor(mindrecord): DTO 기본값·불필요 nullable 제거 — 누락 계약을 정상값으로 은폐하지 않는다 #933 이 4개 파일에서 걷어낸 "isDraft=false 접힘 → 임시저장 노출" 위험의 마지막 잔존 지점이기도 하다 — 같은 정책(계약 부재를 조용한 가정으로 흡수하지 않기)에 맞추면 계약 테스트로 고정할 자리.
• /receiver-auth/* 는 dev 에서 403(전달 조건 미충족)이라 실응답 실측은 불가 — Swagger 대조가 1차 근거이고, 실서버 응답에 isDraft 가 실제로 실리는지는 구현 시 로그로 재확인.