[FEATURE] 링크 검사 분석 요청 및 polling 연동

[kbh0218]

📝 기능 설명

링크 검사 중 화면에서 현재 사용 중인 3초 mock 타이머 흐름을 실제 백엔드 분석 API 연동 흐름으로 교체하고, 분석 완료 결과를 결과 화면까지 전달할 수 있는 구조를 구현합니다.

현재 app/(tabs)/(home)/scanning.tsx는 검사 대상 URL을 받은 뒤 일정 시간이 지나면 mock 결과 화면으로 이동합니다.
이번 작업에서는 백엔드의 분석 요청 API인 POST /api/v1/analyses를 호출하고, 응답으로 받은 analysisId를 기준으로 GET /api/v1/analyses/{analysisId}를 polling하여 실제 분석 상태를 확인합니다.

분석 상태가 succeeded가 되면 응답의 verdict 값에 따라 안전, 주의, 위험 결과 화면으로 이동합니다.
이때 결과 화면에서 실제 분석 결과를 활용할 수 있도록 url, analysisId, AnalysisResponse 전달/수신 구조까지 함께 구현합니다.

분석 API는 Clerk 인증 토큰이 필요한 보호 API이므로, issue #41에서 정리한 공통 API 클라이언트 구조를 사용합니다.

📋 구현할 Task

• 현재 app/(tabs)/(home)/scanning.tsx의 mock 타이머 기반 이동 흐름을 확인했는가?
• 분석 요청 API 타입과 호출 함수를 별도 API 파일로 정리했는가?
• POST /api/v1/analyses 요청 시 Clerk getToken() 기반 인증 헤더가 포함되는가?
• 분석 요청 성공 시 응답의 analysisId와 초기 status를 정상적으로 파싱하는가?
• GET /api/v1/analyses/{analysisId} polling 호출을 구현했는가?
• polling 간격을 2초 기준으로 설정했는가?
• 최대 대기 시간을 30초 기준으로 제한했는가?
• queued 상태에서는 polling을 계속 유지하는가?
• succeeded 상태에서는 verdict 값에 따라 결과 화면으로 이동하는가?
• safe 결과는 scan-result 화면으로 이동하는가?
• caution 결과는 scan-result-caution 화면으로 이동하는가?
• danger 결과는 scan-result-block 화면으로 이동하는가?
• failed 상태 또는 API 에러 발생 시 사용자에게 적절한 안내를 제공하는가?
• 컴포넌트 unmount 시 timer/polling이 정리되어 중복 요청이 발생하지 않는가?
• 결과 화면 이동 시 url, analysisId, AnalysisResponse를 전달하는 구조를 구현했는가?
• 각 결과 화면에서 전달받은 analysisId를 route params 등으로 수신할 수 있는가?
• 각 결과 화면에서 전달받은 AnalysisResponse를 사용할 수 있는 구조인가?
• route params로 직접 전달하기 어려운 분석 응답 데이터는 store/context/query cache 등 적절한 방식으로 관리되는가?
• 결과 화면 새로고침/직접 진입 등 분석 응답 데이터가 없는 경우를 고려했는가?
• issue #41에서 만든 공통 API 클라이언트 패턴을 따르는가?

📎 추가 내용

• 관련 화면

  • app/(tabs)/(home)/scanning.tsx
  • app/(tabs)/(home)/scan-result.tsx
  • app/(tabs)/(home)/scan-result-caution.tsx
  • app/(tabs)/(home)/scan-result-block.tsx

• 관련 API

  • POST /api/v1/analyses
  • GET /api/v1/analyses/{analysisId}

• 요청 예시

{
  "url": "https://example.com"
}