feat(backend): market data provider adapter 계약 정의

[dkfhddla]

Problem

토스증권 API를 첫 테스트 provider로 사용하더라도, Dashboard Schema 생성과 상대성과 계산 로직이 특정 증권사 응답 형식에 직접 의존하면 후속 투자처 API 등록형 구조로 확장하기 어렵다.

Expected Behavior

백엔드는 provider별 API 응답을 공통 내부 모델로 정규화하는 adapter 계약을 제공해야 한다. 계산과 대시보드 API는 provider 구현체가 아니라 정규화된 데이터 모델에 의존해야 한다.

Scope

• read-only market data provider 인터페이스 정의
• 보유 종목, 현재가, 시장 지수 quote, 출처/갱신 시각을 표현하는 내부 모델 정의
• provider 오류, 권한 없음, 데이터 지연 상태를 표현할 수 있는 결과 타입 정의
• 테스트용 fake provider 또는 fixture 추가

Acceptance Criteria

• provider 계약이 보유 종목 목록 조회를 표현한다.
• provider 계약이 복수 종목 현재가 조회를 표현한다.
• provider 계약이 KOSPI/KOSDAQ 지수 조회를 표현한다.
• 모든 provider 결과는 provider명, 데이터 출처, 마지막 갱신 시각을 포함할 수 있다.
• 계산/대시보드 서비스는 provider별 원본 응답 타입에 직접 의존하지 않는다.
• fake provider 기반 단위 테스트가 계약의 기본 동작을 검증한다.

Evidence Pointers

• docs/product-requirements/stock-signal-view.md: REQ-SSV-003 시장 대비 지표 제공 - accepted
• docs/specs/mvp-foundation.md: R-004 상대수익률 산출, KOSPI/KOSDAQ 비교 기준 - accepted
• 사용자 인터뷰: 토스증권 API로 테스트하되 추후 개인 투자자별 투자처 API 등록형 구조 희망 - accepted

Affected Areas

• backend/app/services/
• backend/app/schemas/
• backend/tests/
• docs/arch/

Non-Goals

• 특정 provider 인증 UI
• 주문 실행
• 자동매매

[dkfhddla]

선행 맥락: 이 이슈는 #2의 로컬/모의 데이터 MVP 이후 진행되는 provider 확장 작업입니다.

권장 순서상 #19에서 문서상 범위를 먼저 정리한 뒤 진행하는 것이 안전합니다. #2가 직접 구현하는 상대수익률/대시보드 흐름과 중복되지 않도록, 이 이슈는 특정 증권사 응답을 공통 내부 모델로 정규화하는 read-only provider adapter 계약에 집중합니다.