refactor(receiver): 수신자 상세 애프터노트 제목의 근거 없는 nullable 을 걷는다 (closes 1177) [base: develop]

[OnlyReadOneBook]

Closes #1177

수신자 상세의 애프터노트 제목만 String? 이었다. 서버가 비워 둘 수 없게 강제하는 값이고 FE 의 다른 모든 애프터노트 제목은 이미 non-null 인데, 이 한 곳의 nullable 이 매퍼의 title.orEmpty() 를 낳아 도달 불가능한 «제목 없는 상세 화면» 을 코드로 만들어 두고 있었다.

계약 근거 (Afternote-BE origin/release 실코드, 2026-08-26 확인)

강제 지점	실코드
생성 요청	AfternoteCreateRequest.java:18-21 @NotBlank String title — AfternoteController.java:87·102 가 @Valid 로 발효
엔티티	Afternote.java:34-35 @Column(nullable = false, length = 100)
수정 경로	AfternoteService.java:271 request.getTitle() != null ? request.getTitle() : afternote.getTitle() — null 로 덮이는 경로가 없다
플레이리스트	PlaylistRelationStrategy.java:115 가 atmosphere 없으면 기본 제목으로 반드시 채운다

응답은 그 NOT NULL 컬럼 값을 그대로 싣는다 — ReceivedAfternoteDetailResponse.java 의 조립부 3곳(fromSocial:110 · fromGallery:122 · fromPlaylist:167)이 전부 .title(afternote.getTitle()) 이고, record 의 title 에 @Schema(nullable = true) 가 없다.

임시저장 예외는 논쟁 자체가 성립하지 않는다 — AfternoteReceiverRepository.java:20·30 의 조회 쿼리가 AND a.isDraft = false 로 임시저장을 수신자에게서 아예 배제한다. FE 도 AfternoteSaveState.kt:26 의 TITLE_REQUIRED 로 제목 없는 저장을 에디터에서 거절한다.

dev 서버는 작업 시각(03:40 KST)에 닫혀 있어 실응답 확인은 못 했다. 계약은 위 실코드로 확정된다.

변경

• ReceivedAfternoteDetailDto.title · ReceivedAfternoteDetail.title → String (기본값 없음)
• 매퍼의 title.orEmpty() 2곳 제거
• ReceivedAfternoteDetailTitleContractTest 신설 — 키가 빠지거나 명시적 null 이면 빈 제목으로 성공하지 않고 어느 키 때문인지 남기며 실패함을 고정. NetworkModule.provideJson 의 coerceInputValues 는 기본값이 있어야 동작하므로 이 필드를 구해 주지 않는다
• 딸려 나온 픽스처 보정 — 매퍼 테스트 5곳, LeaveMessageBlockContractTest 의 JSON 1곳. androidTest 3곳은 이미 title 을 명시하고 있어 손대지 않았다

리뷰어에게

와이어까지 좁힌 것은 상세 한정이다. #1010 이 세운 «와이어 관용 · 도메인 엄격» 방침의 논거는 페이징 목록의 실패 폭(ReceiverAfternotePagingSource.load() 가 항목 하나 때문에 페이지 전체를 날림)이고, #1010 자신이 "결정할 것 2. 상세 경로의 기각 의미" 를 미해결로 남겼다. 상세는 응답 하나가 화면 하나라 «항목만 떨어뜨린다» 가 성립하지 않고, 제목 없는 상세는 어차피 못 그린다. 수신 목록 DTO(ReceivedAfternoteDto)는 손대지 않았다.

인접 작업과의 경계:

• refactor(afternote): 응답 DTO 보정형 기본값 정리 — 누락 계약을 빈 값으로 은폐하지 않는다 (#789·#790 애프터노트 판) #957 — 같은 ReceiverAfternoteDto.kt 의 보정형 기본값 4건(emptyList()·0)을 다룬다. title: String? = null 은 그 목록에 없다(보정형 기본값이 아니라 불필요한 nullable)
• refactor(dto): 응답 DTO 를 BE 실코드에 동기화 — 유령 필드 9건·누락 필드 21건 #676 — 필드 구성(유령·누락) 동기화. 이 DTO 에 대해선 credentials 유령 여부만 «판단 필요» 로 남아 있다
• fix(receiver): 남기지 않은 계정 정보에 마스킹을 그리지 않는다 (closes 619) [base: develop] #1169(fix/619) — 같은 매퍼의 credentials 쪽 orEmpty() 를 걷어내며 serviceName = title.orEmpty() 바로 아랫줄을 고친다. 텍스트 충돌이 예상되고, 어느 쪽이 먼저 들어가든 해소는 한 줄이다

범위 밖: ReceivedDetailContentUiModel.kt:36·46 의 serviceName: String = "" 등 UI 표시 모델의 보정형 기본값. 같은 파일의 finalWriteDate·accountId·password 가 같은 패턴이라 serviceName 만 떼면 오히려 어긋나고, 그중 둘은 #1169 가 이미 손대는 중이다.

타임레터와 같게 다루지 말 것: ReceivedTimeLetterResponse.java:92 는 isAvailable ? timeLetter.getTitle() : null 로 진짜 조건부 null 이다(senderName·createdAt·isRead 도 같은 게이트). 그쪽 nullable 은 근거가 있다.

검증 (로컬, origin/develop e1b307eb 기준)

명령	결과
:feature:receiver:data:testDebugUnitTest (--rerun-tasks)	✅ 신설 계약 테스트 3건 포함 전량 통과
:app:compileDebugUnitTestKotlin · :app:compileDebugAndroidTestKotlin	✅ BUILD SUCCESSFUL — 새 경고 없음(잔여 경고는 develop 에서 물려받은 것)
:feature:{receiver:data,receiver:domain,receiver:presentation,afternote:data}:ktlintCheck	✅
:feature:afternote:data:testDebugUnitTest · :feature:receiver:presentation:testDebugUnitTest	✅

ReceivedAfternoteDetail·ReceivedAfternoteDetailDto 사용처는 androidTest 포함 전수 조사했다.

QA·시안 대조: 해당 없음. 화면에 그려지는 문자열이 바뀌지 않는다 — 계약상 title 은 늘 채워져 있었고, 이 PR 은 «올 수 없는 값» 을 타입에서 지웠을 뿐이라 정상 응답의 렌더 결과가 동일하다. 달라지는 것은 계약이 깨졌을 때의 거동(빈 제목 화면 → 파싱 실패)뿐이다.