Fix ResultController auth principal type and OcrService error code after merge conflict

[Copilot]

The OCR-based tax refund automation pipeline had two runtime bugs introduced during merge conflict resolution that would silently break the /api/result endpoints and return a misleading HTTP status when OCR processing is incomplete.

Changes

ResultController — wrong @AuthenticationPrincipal type

JwtAuthenticationFilter stores a Long (cpaId) as the Security principal, but ResultController was extracting UserDetailsImpl — which resolves to null at runtime, causing NPE on .getCpaId(). All other controllers already use Long cpaId correctly.

// Before (broken — principal is Long, not UserDetailsImpl)
public ApiResponse<RefundResultsResponse> getRefundResults(
        @AuthenticationPrincipal UserDetailsImpl userDetails, @PathVariable Long caseId) {
    return ApiResponse.ok(refundResultService.getRefundResults(userDetails.getCpaId(), caseId));
}

// After (consistent with all other controllers)
public ApiResponse<RefundResultsResponse> getRefundResults(
        @AuthenticationPrincipal Long cpaId, @PathVariable Long caseId) {
    return ApiResponse.ok(refundResultService.getRefundResults(cpaId, caseId));
}

OcrService — 429 used where 409 was intended

confirmOcrDataAndCalculate() was throwing COMMON429 (Too Many Requests) for the "OCR not yet READY" case, with a comment acknowledging 409 Conflict was the correct semantic. ErrorCode.OCR409 already existed in the enum but was never wired up.

// Before
throw new ApiException(ErrorCode.COMMON429, "OCR 분석이 아직 완료되지 않았습니다...");

// After
throw new ApiException(ErrorCode.OCR409, "OCR 분석이 아직 완료되지 않았습니다...");

Original prompt

세무사/고객의 원천징수영수증(PDF) 을 업로드하면 OCR로 핵심 항목을 구조화하고, 케이스별 자료를 관리해 경정청구(환급) 산출/결과물 생성까지 이어지는 자동화 서비스

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.