feat: 전체 업무 유형과 사업장 공통 대상 확장

[hywznn]

왜 필요한가요?

기존 세 가지 연장 Task만 저장할 수 있던 구조를 전체 Intent 업무 유형으로 확장하고, 아직 근로자가 정해지지 않은 사업장 공통 업무도 안전하게 저장합니다.

Refs #85

무엇이 바뀌나요?

• DOCUMENT_REQUEST, WORKER_ONBOARDING, PAYROLL_EXPLANATION, EMPLOYMENT_CHANGE, WORK_INSTRUCTION Task 유형을 추가했습니다.
• target_type = WORKER | COMPANY 모델을 추가했습니다.
• WORKER 업무는 기존처럼 worker_id와 case_id가 필요합니다.
• COMPANY 업무는 worker_id와 case_id 없이 독립 Task로 저장하며 Workflow Case를 만들지 않습니다.
• 기존 요청에서 target_type을 생략하면 worker_id 유무로 호환 처리합니다.
• 목록 API에 target_type과 source 필터를 추가했습니다.
• FILE_IMPORT, WORKER_RESPONSE 출처를 추가했습니다.
• Server가 사용하는 Knowledge projection에 canonical Workflow 5개를 연결했습니다.
• 사업장 공통 업무에 Worker Link나 근로자 문서가 잘못 연결되지 않도록 방어했습니다.
• Flyway V28에서 nullable FK와 대상 조합 CHECK 제약을 추가했습니다.

기존 구조 보호

• 기존 연장 Task와 AI 후보 기반 세 Task 생성 흐름을 유지합니다.
• COMPANY Task는 [Case][P0] Case·Workflow Snapshot·업무함 Projection 구현 #83 Case 구조에 억지로 포함하지 않습니다.
• Knowledge 원본 저장소는 수정하지 않고 Server가 사용하는 projection만 확장했습니다.
• 자동 승인·자동 발송·새 Task 상태는 추가하지 않았습니다.

검증

• ./gradlew clean test — BUILD SUCCESSFUL
• 전체 canonical Task 유형 생성 검증
• WORKER·COMPANY 대상 조합과 조회 필터 검증
• OpenAPI 및 DB CHECK 제약 검증

⚠️ Flyway 예약 및 병합 조건

• 현재 main, 열린 PR, 원격 브랜치에 V28을 사용하는 다른 작업이 없음을 확인했습니다.
• 이 PR이 V28을 사용합니다.
• 병합 직전에 최신 main에서 V28 중복 여부를 다시 확인합니다.
• GitHub CI와 PostgreSQL 전용 Migration·Tenant·RLS 검증을 통과한 뒤 병합합니다.

[krestar]

전체 Task 유형 확장과 WORKER/COMPANY 대상 규칙이 API, 도메인, 영속성, DB 제약까지 일관되게 반영된 점 확인했습니다.
기존 WORKER 흐름의 호환성을 유지하면서 COMPANY Task의 Case 생성 및 Worker Link,문서 오연결도 잘 방어되어 있습니다.
CI, 통합 테스트도 통과해 승인합니다.

[krestar]

migration V28 확인했습니다