refactor(core): UiText.DynamicOrResource 를 걷는다 — 예외 원문 노출을 문법으로 권한다 (#1882 후속) #1887

작업 유형

refactor — 동작 변경 없이 구조·경계 개선

주 담당 모듈

core — core:ui

무슨 일인가

UiText.DynamicOrResource 는 안티패턴을 문법으로 권한다.

is UiText.DynamicOrResource -> value ?: stringResource(fallbackResId)

value 가 있으면 fallback 은 아예 쓰이지 않는다. 호출부가 value = e.message 를 넘기면
직렬화 예외 문구·서버 오류 원문·SocketTimeoutException 같은 영문 스택 용어가 그대로
사용자 화면에 실린다.

가정이 아니라 한 번 일어났던 일이다 — EmotionAnalysisContractTest.kt:112-113 이 그 사고를
주석으로 기록하고 있다. 그때는 DTO 필드를 옵셔널로 내려 그 예외만 막았고, 노출 기전은 그대로
살아 있었다.

이 저장소는 이미 반대 방향으로 판정했다: 서버 오류 원문은 화면에 내지 않고 로그·텔레메트리로만
보낸다 (#1339 에서 수신자 흐름에 적용).

지금 상태

#1882 가 마음의 기록에 남아 있던 마지막 프로덕션 소비처 2곳을 걷었다. 지금 이 타입을 쓰는
src/main 자리는 core:ui 의 정의 자신뿐이다.

$ git grep -n "DynamicOrResource" -- '*/src/main/*'
core/ui/src/main/kotlin/com/afternote/core/ui/UiText.kt:25:    data class DynamicOrResource(
core/ui/src/main/kotlin/com/afternote/core/ui/UiText.kt:54:        is UiText.DynamicOrResource -> {

무엇을 하는가

1. UiText.DynamicOrResource 와 asString() 의 그 분기를 지운다.
2. 실행되는 테스트의 타입 참조가 남아 있으면 정리한다. 타 담당 모듈의 과거 회귀 원인을 기록한 주석은 유지한다.
3. KDoc 이 「서버/예외가 메시지를 주면 그대로」로 이 사용법을 권하고 있으니 함께 걷는다.

걷어내면 같은 실수를 다시 할 수 있는 문법이 사라진다. 예외 원문을 화면에 실으려면
그때는 새 타입을 의도적으로 만들어야 하고, 그 자리에서 판정이 한 번 더 걸린다.

왜 분리했는가

#1882 는 mindrecord 소관이고 이 타입은 core:ui 라 담당이 다르다
(reconcile-issue-metadata.mjs:49). #1882 는 소비처를 0 으로 만드는 데까지 하고, 타입 삭제는
여기로 넘긴다.

완료 조건

• 프로덕션 선언·사용처와 실행되는 테스트에서 DynamicOrResource 참조가 0건. 마음의 기록 테스트에 남은 과거 사고 설명 주석은 실행 참조가 아니므로 수정하지 않는다.
• :core:ui 와 그 소비 모듈이 컴파일·테스트 통과

착수 시 확인한 후속 PR 소비처

현재 develop에는 실제 생성·소비가 없지만, 기존 설정 PR #1925와 #1930의 연결 계정 문자열 변환에 해당 타입의 when 분기가 남아 있다. 독립 코어 삭제 PR을 만든 뒤 이 두 소비 브랜치에도 같은 삭제를 반영하고 앱 컴파일·관련 설정 회귀를 확인한다. 타 담당 모듈의 프로덕션·테스트 파일은 변경하지 않는다.