refactor: 설정 MVI와 저장·Repository 책임을 최종 계약으로 통합 (#1502)

[OnlyReadOneBook]

변경

Closes #1502 · Closes #1691 · Closes #1739 · Closes #1429 · Refs #1805

설정의 6개 ViewModel에서 Channel/MutableSharedFlow 이벤트를 UiState 신호로 옮기고, 동시에 MviViewModel·Intent·순수 reduce를 적용합니다. 후속 PR #1925와 #1930이 이벤트 코드를 추가한 뒤 다시 MVI로 옮기는 재작성을 없앱니다.

• 대상: 연결 계정, 프로필 수정, 수신자 등록·수정, 전달 조건, 푸시·마케팅 알림 설정.
• 모든 변경은 onIntent → dispatch → reduce로 처리하며, 화면은 ObserveSignal과 Consume Intent로 신호를 소비합니다. 인증·스낵바는 신호 소비로 취소되지 않게 화면 코루틴에서 처리합니다.
• 저장 성공 신호를 수집자가 없을 때도 보존하고 중복 제출을 막습니다. 늦은 소비는 새로운 다른 신호를 지우지 않습니다.
• 마케팅 동의 실패의 롤백·진단·화면 비활성 중 안내 미재생 계약을 유지합니다. 푸시 저장 실패의 마지막 요청 재시도와 토글별 중복 요청 방지도 유지합니다.
• Konsist가 MVI 미전환 예외를 포함한 모든 feature ViewModel의 새 이벤트 스트림을 차단합니다. 실제 소비처가 생긴 MviViewModel/ObserveSignal의 임시 visibility 예외도 제거합니다.

확정된 저장·소유 계약 통합

후속 이슈가 같은 ViewModel과 fixture를 다시 작성하지 않도록 #1691·#1739·#1429를 이 PR에 함께 통합합니다.

• 수신자/프로필 소비자는 UserReceiverRepository/MyProfileRepository만 주입합니다. 계정 삭제·연결은 SettingAccountRepository, 서비스 알림·마케팅 동의는 SettingNotificationRepository를 설정 domain/data가 소유합니다. core의 합본 계약·구현·fake에서 해당 8멤버를 제거하고 앱 Hilt 대체 모듈도 옮겼습니다.
• UpdateReceiverInfoUseCase가 기본정보 → 인사말 저장 순서와 부분 성공을, UpdateTimeLetterDeliveryConditionUseCase가 다른 콘텐츠 보존·TIME_LETTER 합성·기간 정규화를 소유합니다. UI 문구·로딩·중복 탭은 ViewModel에 유지합니다.
• 좁은 fixture와 호출 기록 타입까지 실제 소비자에 연결하여 합본 fake 제거 때 같은 테스트를 다시 고칠 필요를 없앴습니다.
• setting domain은 기존 Java 11 단독 설정 대신 core domain과 같은 JVM domain 규약을 사용합니다.

선행·후속

실제 base는 #1962 codex/1695-setting-nav3입니다. 이 PR → #1925 → #1930 순서로 연결하며, #1927은 이 PR을 기반으로 별도 패스키 변경을 유지합니다. #1805의 다른 ViewModel 전체를 이 PR에서 전환하지 않습니다.

최신 통합 검증

• setting domain 7, setting data 7, core data 61, core domain 12, setting presentation 69, Konsist 56 테스트 통과.
• 앱 main/unit/androidTest Kotlin 컴파일 통과. 관련 모듈 ktlint 및 diff 공백 검사 통과.
• 실제 Nav3 SavedState serializer를 사용하는 #1962의 정정 테스트도 부모에서 통합했습니다. 화면 배치 변경이 없어 screenshot baseline은 유지합니다.
• Kotlin LSP documentSymbol은 초기화 미완료로 두 차례 실패하여 현재 소스 대조와 컴파일·회귀 테스트로 검증했습니다.

기존 MVI 검증

• setting presentation 단위 테스트 69건, Konsist 56건 통과(실패·오류 0)
• setting presentation/Konsist ktlintCheck 통과
• setting compileDebugScreenshotTestKotlin, 앱 compileDebugKotlin, compileDebugUnitTestKotlin, compileDebugAndroidTestKotlin 통과
• 신규 회귀 검증: 수집자가 없는 동안 성공 신호 유지, 소비 후 동일 성공 재전달, 저장 중 중복 요청, 실패 후 재시도, 늦은 소비와 새 신호 경합, MVI 예외 VM의 이벤트 스트림 재유입 차단

화면 배치를 변경하지 않아 기존 screenshot baseline을 유지합니다. 외부 소셜 로그인 앱의 실제 인증 왕복은 새로 실행하지 않았습니다.

CI Test Plan

{
  "androidTest": {
    "mode": "full",
    "reason": "설정 6개 ViewModel의 Hilt 생성과 저장 성공·인증 신호 소비 경로를 동시에 전환하므로 기존 설정 계측 흐름을 포함한 전체 lane으로 통합 동작을 검증한다. 로컬에서는 화면·상태 회귀 테스트와 앱/계측 코드 컴파일을 확인했다.",
    "tests": []
  }
}

[github-actions]

열린 PR 중 이 PR 과 같은 파일을 서로 다르게 고친 것이 있다. 어느 쪽이 먼저 머지되든 나중 쪽은 base 를 병합해야 통과한다 (#1750).

• refactor(afternote): 합본 UserRepository 대신 좁은 계약 UserReceiverRepository·MyProfileRepository 를 주입한다 (#1743) #1837 — feature/afternote/presentation/src/test/kotlin/com/afternote/feature/afternote/presentation/AfternoteAuthorTestFixtures.kt
• refactor(afternote): 편집기 MVI와 소비 경계를 통합한다 (#1804) #1972 — konsist/src/test/kotlin/com/afternote/konsist/ProductionVisibilityKonsistTest.kt
• refactor(setting): 미사용 선언과 파일명 정리 (#1064) #2005 — konsist/src/test/kotlin/com/afternote/konsist/MviContractKonsistTest.kt
• refactor(setting): RadioGroup을 공용 그룹 API로 이관 (#1396) #2015 — konsist/src/test/kotlin/com/afternote/konsist/ProductionVisibilityKonsistTest.kt
• refactor(setting): domain에 공용 JVM 규약 적용 (#1305) #2023 — feature/setting/domain/build.gradle.kts, feature/setting/domain/src/main/java/com/afternote/feature/setting/domain/Notice.kt
• refactor(receiver): 구 수신자 흐름 MVI 전환 철회 (#1803) #2039 — konsist/src/test/kotlin/com/afternote/konsist/MviContractKonsistTest.kt
• refactor(setting): presentation을 기능별 폴더로 정리 (#1088) #2053 — feature/setting/presentation/src/test/kotlin/com/afternote/feature/setting/presentation/SettingFlowTest.kt
• feat(receiver,setting): 수신자 등록에 카카오톡 초대 발급·수락 흐름을 잇는다 (#944) #2109 — feature/setting/presentation/src/test/kotlin/com/afternote/feature/setting/presentation/SettingCompletionTest.kt

머지 자체는 GitHub 이 막는다 — 한쪽이 들어가면 다른 쪽은 CONFLICTING 이 되어 merge queue 에 못 들어간다.
이 라벨은 그 전에 순서를 정하라는 신호다. 먼저 갈 쪽을 정하고, 나중 쪽은 그 머지 뒤에 base 를 병합한다.
상대 PR 에도 같은 안내가 달린다.

이 코멘트는 리컨사일러가 매 실행 현재 상태로 고쳐 쓴다. 해소되면 sibling-conflict 라벨은 자동으로 떨어진다.

[github-actions]

이 PR 은 codex/1695-setting-nav3 와 충돌 상태이고, 그래서 CI 가 돌지 않는다.

pull_request 워크플로는 base 와 head 를 합친 가상 머지 커밋(refs/pull/<N>/merge)에서
실행되는데, 충돌이면 GitHub 이 그 ref 를 만들지 못해 워크플로가 트리거조차 되지 않는다.
체크가 실패하는 것이 아니라 아예 생성되지 않으므로, 새 커밋을 올려도 no checks reported
인 채 최신 커밋이 한 번도 검증되지 않은 상태로 남는다 (#1028).

codex/1695-setting-nav3 를 병합해 충돌을 풀면 검증이 다시 돈다. 해소되면 이 라벨은 자동으로 떨어진다.

[OnlyReadOneBook]

PM 결정을 기다리는 항목은 깃허브에 열어 두지 않고 피그마 질문 한 자리에만 둔다(2026-09-18 일혁 결정). 이 PR 은 #1962(설정 Nav3 이관) 위에 쌓여 있고, #1962 는 설정 메인 사후 전달 조건 진입 경로의 PM 답을 기다린다: https://www.figma.com/design/UP9ZR186jHvRBicjA2SOea/?node-id=4327-64430#1923797606

그래서 사슬 13건을 함께 닫는다. 브랜치와 승인 리뷰는 그대로 남아 있고, 답이 오면 그 답을 근거로 #1962 부터 다시 열어 같은 순서로 올린다. 코드가 틀려서 닫는 것이 아니다.