CupixAuth#getSession missing retry on 504 — no retryable wrapper

Validation: cf86fc53-a9cf-453e-bbda-7c465197898b

Plan Item	Status	Evidence
`cupix-auth.ts`: `getSession` 호출을 `this.retryable(...)`로 감싼다	PASS	`applications/agents/packages/api/src/authentication/cupix-auth.ts` line 321: `const res = await this.retryable(() => this.sessionApi().getSession(['id']));` (기존 line 321 `await this.sessionApi().getSession(['id'])` 대체)
`potree-service.ts`: 5xx는 `logger.warn`, 그 외는 `logger.error`로 분기	PASS	`applications/agents/packages/cupix-tesla-potree-agent/src/potree-service.ts` lines 529-535: `statusCode` 추출 후 `isRetriableUpstream` 조건으로 `logger.warn` / `logger.error` 분기 처리
기존 fingerprint 로그 포맷 문자열 유지	PASS	lines 532, 534 모두 `'PotreeService::handlingMessageErrors
`retryable` 헬퍼 signature/동작 변경 없음	PASS	diff에 `retryable` 정의부 변경 없음, 호출 사이트만 추가됨

Criterion	Status	Evidence
`getSession` 본문에서 `this.sessionApi().getSession(['id'])` 호출이 `this.retryable(...)`로 감싸짐	PASS	`cupix-auth.ts` line 321: `this.retryable(() => this.sessionApi().getSession(['id']))`
`handlingMessageErrors` 최종 로그가 5xx(>=500, <600)에서 `logger.warn`, 그 외 `logger.error`로 분기	PASS	`potree-service.ts` line 530: `statusCode >= 500 && statusCode < 600` 조건, lines 531-535의 if/else 분기가 정확히 warn/error로 나뉨
fingerprint 로그 포맷 문자열 유지	PASS	두 branch(line 532 warn, line 534 error) 모두 원본과 동일한 포맷 문자열, `JSON.stringify(errorAndMessage)` 인자 유지
`retryable` 헬퍼 signature/동작 미변경	PASS	diff 내 `retryable` 정의 수정 없음
`tsc --build` lint/type 이슈 없음	UNVERIFIABLE	Cannot verify from diff — requires runtime check. `error?.statusCode ?? error?.response?.statusCode` 표현은 optional chaining으로 문법적 문제는 없으며 `error` 변수는 외곽 함수 스코프의 catch 인자로 추정됨

차단 이슈 없음.

potree-service.ts line 529의 error?.statusCode ?? error?.response?.statusCode 접근은 error가 외곽 스코프의 catch 바인딩이거나 매개변수라고 가정한다. Diff 컨텍스트만으로는 완전한 스코프 확인이 불가하나, logger.error 호출과 동일한 위치에 있으므로 이미 접근 가능한 심볼일 가능성이 높다.
statusCode의 타입이 unknown일 경우 typeof statusCode === 'number' 가드로 안전하게 좁혀지므로 런타임/타입 안정성 양호.
로그 포맷 문자열이 두 branch에 중복된다. 향후 리팩터링 여지가 있으나 fingerprint 유지 요구사항에 부합하므로 지금은 의도된 선택으로 판단.
Plan에서 언급된 Constants.MaxRetries=3 재시도 동작은 retryable 헬퍼 내부 로직에 의존하며 diff로는 검증 불가 — 헬퍼 시그니처 미변경 전제로 통과.