refactor(receiver): 구 수신자 흐름 MVI 전환 철회 (#1803)

[OnlyReadOneBook]

구 수신자 인증·목록 흐름에 추가한 MVI 전환을 철회합니다. 이메일 인증·마스터키·로컬 SenderRegistry뿐 아니라 발신자 상세와 서류 제출도 교체되는 인증 컨텍스트에 연결되어, 독립적으로 남길 수 있는 MVI 범위가 없습니다.

BE main의 7c961ec3e2eb6fe3d0d87d4ba4e2dea312fdcf7f에서 ReceivedRecordController는 회원 인증과 receiverId 기반 조회·업로드·제출을 사용합니다. 이 PR의 기존 이메일 인증 캐시, 전역 마스터키 저장, receiverId 없는 제출 배선은 해당 계약으로 전환할 때 다시 바뀝니다. 관련 결함 기록은 #607입니다.

47개 변경 파일을 실제 base 0c5748d0e2cb34fa3dab8a2cae785d2ac4f716cf로 복원했습니다. 철회 커밋 9392ce441의 전체 트리는 그 base와 같으며, 기존 수신자 기능·테스트와 이미 반영된 Nav3 변경은 유지됩니다. 새 API 전환을 구현한 것이 아닙니다.

검증: 수신자 testDebugUnitTest, konsist:test, 수신자 ktlintCheck 통과. 에뮬레이터 QA는 실행하지 않았습니다.

Refs #1803. 이 PR은 병합하지 않고 닫습니다. #1803도 MVI 구현 완료로 계산하지 않습니다.

[github-actions]

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

• refactor(afternote): 편집기 외 ViewModel 8개 MVI 전환 (#1968) #2021 — konsist/src/test/kotlin/com/afternote/konsist/MviContractKonsistTest.kt

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

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

[github-actions]

이 PR 은 develop 와 충돌 상태이고, 그래서 CI 가 돌지 않는다.

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

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

[OnlyReadOneBook]

이 head 의 체크 전량 초록 재확인. 검색 status: 색인 갱신용 코멘트(승인·체크 완료 뒤 이벤트가 없어 색인이 pending 에 머물러 있었다).