fix(auth): RLS 활성화 후 프로필 조회·수정 500 오류 수정

[krestar]

왜 필요한가요?

PostgreSQL RLS 활성화 후 배포 환경의 프로필 화면에서 다음 API가 500 Internal Server Error를 반환합니다.

GET /api/v1/auth/me/profile

배포 환경에서 Demo 계정으로 로그인한 뒤 프로필 화면 진입 시 동일 오류를 재현했습니다.

원인은 AuthService.currentProfile()과 updateProfile()이 transaction은 시작하지만,
RLS가 사용하는 transaction-local tenant context인 app.company_id를 설정하지 않는 것입니다.

이 상태에서는 인증된 JWT에 올바른 company_id가 있어도 user_account 조회가 RLS에 의해
fail-closed 되어 현재 사용자 행을 찾지 못합니다.

Related: #34

무엇이 바뀌나요?

• AuthService.currentProfile()에서 현재 인증 사용자의 companyId를 tenant context에 설정합니다.
• AuthService.updateProfile()에도 동일한 tenant context 설정을 적용합니다.
• 기존 userId + companyId Repository 조건과 권한 검사는 그대로 유지합니다.
• API 계약, DB schema, Flyway migration 변경은 없습니다.
• PostgreSQL restricted runtime role 환경에서 프로필 GET/PATCH 경로를 검증하도록 기존 E2E를 보강합니다.

핵심 변경은 다음과 같습니다.

tenantDatabaseContext.setCompanyIdForCurrentTransaction(companyId);

장애 영향

RLS 활성화 이후 다음 경로가 영향을 받습니다.

• GET /api/v1/auth/me/profile
• PATCH /api/v1/auth/me/profile

로그인, /api/v1/auth/me, Worker/Task 등 기존 tenant context 적용 경로는 변경하지 않습니다.

검증

• 배포 환경에서 RLS 활성화 후 GET /api/v1/auth/me/profile 500 재현
• 누락된 tenant context 경로 확인
• PostgreSQL restricted-role 프로필 GET/PATCH 회귀 테스트 추가
• Required CI checks

배포 후 Smoke

1. Demo 계정 로그인
2. /profile 진입 후 프로필 정보 정상 조회 확인
3. 이름 또는 전화번호 수정 후 저장 확인
4. Test Company 계정에서도 동일하게 정상 동작하는지 확인
5. Demo/Test Company 간 데이터 격리가 유지되는지 확인

이번 PR은 RLS를 비활성화하거나 우회하지 않고,
누락된 인증 프로필 transaction을 기존 tenant isolation 계약에 맞추는 핫픽스입니다.