[FEATURE] 저장 링크 API 연동 및 제목 수정 기능 적용

[kbh0218]

📝 기능 설명

safe/caution 검사 결과 화면에서 실제 저장 링크 API를 호출하도록 연동하고, 기존 saved-links-context.tsx의 mock 기반 저장 링크 상태를 백엔드 API 기반 목록/북마크/삭제/제목 수정 흐름으로 교체합니다.

현재 저장 링크 관련 화면과 context는 대부분 프론트 mock 데이터 기준으로 동작하고 있습니다.
이번 작업에서는 분석 완료 후 전달받은 analysisId를 사용해 POST /api/v1/saved-links로 링크를 저장하고, 저장 링크 목록 화면에서는 GET /api/v1/saved-links 응답을 기준으로 실제 저장된 링크를 표시합니다.

또한 저장 링크의 더보기 버튼(more button) 메뉴에서 현재 표시되는 북마크 추가 항목을 제목 수정으로 변경합니다.
제목 수정을 누르면 폴더명 수정과 동일한 형태의 모달을 띄우고, 입력받은 제목을 PATCH /api/v1/saved-links/{id}/title API와 연동하여 실제 저장 링크 제목이 변경되도록 구현합니다.

북마크 상태 변경과 링크 삭제도 기존 mock 상태 변경이 아니라 각각 PATCH /api/v1/saved-links/{id}/bookmark, DELETE /api/v1/saved-links/{id} API를 통해 처리합니다.

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

📋 구현할 Task

• app/(tabs)/(home)/scan-result.tsx에서 safe 결과 링크 저장 흐름을 확인했는가?

• app/(tabs)/(home)/scan-result-caution.tsx에서 caution 결과 링크 저장 흐름을 확인했는가?

• 결과 화면에서 전달받은 analysisId를 사용해 POST /api/v1/saved-links를 호출하는가?

• 저장 요청 시 analysisId, categoryId, title, description 요청 구조를 백엔드 계약에 맞게 구성했는가?

• 저장 성공/실패/중복 저장/API 에러 발생 시 사용자에게 적절한 피드백을 제공하는가?

• 저장 중 버튼 중복 클릭으로 중복 요청이 발생하지 않도록 처리했는가?

• danger 결과 화면에는 저장 기능을 붙이지 않는가?

• saved-links-context.tsx의 mock 데이터 의존성을 실제 API 기반 상태로 교체했는가?

• 저장 링크 목록 조회를 GET /api/v1/saved-links API와 연동했는가?

• 목록 조회 시 categoryId, bookmarked, cursor, size query 사용 여부를 현재 화면 흐름에 맞게 검토했는가?

• API 응답의 items, hasNext, nextCursor 구조를 프론트 상태에 맞게 반영했는가?

• 목록 로딩/빈 목록/API 에러 상태를 처리했는가?

• 북마크 변경을 PATCH /api/v1/saved-links/{id}/bookmark API와 연동했는가?

• 북마크 변경 성공 시 응답의 isBookmarked 값을 화면 상태에 반영하는가?

• 링크 삭제를 DELETE /api/v1/saved-links/{id} API와 연동했는가?

• 삭제 성공 시 목록에서 해당 링크가 제거되는가?

• 북마크/삭제 실패 시 화면 상태가 잘못 남지 않도록 처리했는가?

• 저장 링크 더보기 버튼(more button) 메뉴의 북마크 추가 항목을 제목 수정으로 변경했는가?

• 제목 수정 클릭 시 폴더명 수정과 동일한 형태의 모달이 표시되는가?

• 제목 수정 모달에서 현재 링크 제목을 초기값으로 보여주는가?

• 제목 수정 모달에서 입력한 제목으로 PATCH /api/v1/saved-links/{id}/title API를 호출하는가?

• 제목 수정 성공 시 응답의 title 값을 목록/context 상태에 반영하는가?

• 빈 제목, 500자 초과, 중복 제목 등 API 에러 상황을 사용자에게 안내하는가?

• 제목 수정 취소 시 기존 제목과 목록 상태가 유지되는가?

• issue #41에서 만든 공통 API 클라이언트 패턴을 따르는가?

• 기능별 API 파일에서 API base URL을 새로 만들지 않았는가?

• 기능별 API 파일에서 fetch()를 직접 호출하지 않았는가?

• 기능별 API 파일에서 Authorization 헤더를 직접 붙이지 않았는가?

• 기능별 API 파일에서 백엔드 { data: ... } 응답을 직접 unwrap하지 않았는가?

• Clerk 세션 토큰이 필요한 API는 authenticatedApiRequest를 사용하는가?

• 보호 API 호출이 /auth/me 수동 사전 호출에 의존하지 않는가?

• 204 No Content 응답인 삭제 API가 공통 클라이언트 흐름에서 정상 처리되는가?

📎 추가 내용

• 관련 화면

  • app/(tabs)/(home)/scan-result.tsx
  • app/(tabs)/(home)/scan-result-caution.tsx
  • app/(tabs)/(home)/saved-links.tsx

• 관련 context

  • context/saved-links-context.tsx

• 관련 API

  • POST /api/v1/saved-links
  • GET /api/v1/saved-links
  • DELETE /api/v1/saved-links/{id}
  • PATCH /api/v1/saved-links/{id}/bookmark
  • PATCH /api/v1/saved-links/{id}/title

• 저장 요청 예시

{
  "analysisId": "uuid",
  "categoryId": null,
  "title": "required title",
  "description": "optional description"
}