feat: 에러 code → 문구 싱글 소스 카탈로그 구축

[iOdiO89]

사용자 대면 에러 문구가 서버(detail)와 클라에 흩어져 있어 같이 code 기반으로 바꾸기로 함.
서버는 문구를 code로 이관(에픽 #728), 클라는 그에 맞춰 code → 문구 카탈로그를 만든다.

왜 @piki/core

• 에러 문구는 web·app(RN) 둘 다 필요 → 공유하려면 apps/web이 아니라 packages/core에 두고 index.ts barrel로 export
• web/app 모두 @piki/core에서 import

결정 사항

1. 카탈로그 위치는 @piki/core (web/app 공유)
2. 400은 COMMON-INVALID-INPUT 하나로 통합 — 개별 문구 필요한 검증은 도메인 code로 분리 (LINK-001~004, USER-006/012/013 등)
3. 전환기 문구 우선순위: code → detail → generic
4. 5xx는 문구 매핑만 — 재시도 동작(Retry-After/backoff)은 서버 503 도입 시 후속
5. 비도달 예외 제외 — EXTRACTOR-*, SNAPSHOT-*는 비동기 워커 전용(HTTP 비도달)
6. 번호 안정성 — code는 클라 계약, 삭제돼도 결번 유지·재사용 금지

작업 상세 내용

@piki/core (카탈로그 본체)

• consts/errorCode.ts — code 상수 + ERROR_MESSAGE_MAP: Record<code, 문구>
• types/error.ts — 에러 code 유니온 타입 (미지 code 허용 (string & {}) 병행)
• utils/getErrorMessageByCode.ts — 순수 조회 헬퍼 (code → 문구, 없으면 fallback), 플랫폼 의존 X
• index.ts barrel export

apps/web

• utils/getApiErrorMessage.ts — axios 파싱은 유지, 문구 결정은 core 헬퍼 위임 (code → detail → generic)
• types/api.ts — ApiErrorResponseT.code를 core 타입으로 교체
• 개별 화면 분기 도메인 code 정리 (예: LINK-004 "지원하지 않는 쇼핑몰" → 이미지 직접 등록 유도)

apps/app

• 메시지 노출 지점 조사 후 @piki/core 카탈로그로 일원화