feat(approvals): Approval Flow v2 프런트엔드 전면 개편

- 환경/라우터 모듈에 approval_flow_v2 토글을 추가하고 FeatureFlags 초기화를 연결 (.env*, lib/core/**)
- ApiClient 빌더·ApiRoutes 확장과 ApprovalRepositoryRemote 리팩터링으로 include·액션 시그니처를 정합화
- ApprovalFlow·ApprovalDraft 엔티티/레포/유즈케이스를 도입해 서버 초안과 단계 액션(승인·회수·재상신)을 지원
- Approval 컨트롤러·히스토리·템플릿 페이지와 공유 위젯을 재작성해 감사 로그·회수 UX·템플릿 CRUD를 반영
- Inbound/Outbound/Rental 컨트롤러·페이지에 결재 섹션을 삽입하고 대시보드 pending 카드 요약을 갱신
- SuperportDialog·FormField 등 공통 위젯을 보강하고 승인 위젯 가이드를 추가해 UI 가이드를 정리
- 결재/재고 테스트 픽스처와 단위·위젯·통합 테스트를 확장하고 flutter_test_config로 스테이징 호스트를 허용
- Approval Flow 레포트/플랜 문서를 업데이트하고 ApprovalFlow_System_Integration_and_ChangePlan.md를 추가
- 실행: flutter analyze, flutter test

AGENTS.md

@@ -9,6 +9,7 @@ Place all Flutter source in `lib/`, keeping cross-cutting pieces in `lib/core/`
 - `flutter test` — run the unit/widget suite; add `--coverage` when validating overall health.
 - `flutter run -d chrome --web-renderer canvaskit` — local web run matching production rendering.
 - `dart run build_runner build --delete-conflicting-outputs` — regenerate freezed/json_serializable files when models change.
+- After every code addition, modification, or deletion, run both `flutter analyze` and `flutter test` before considering the task complete.
 
 ## Coding Style & Naming Conventions
 Use Flutter’s two-space indentation and run `dart format .` before committing. Follow the Clean Architecture layering: DTOs/remote in `data`, domain interfaces/use cases in `domain`, controllers/widgets in presentation. File names use `snake_case.dart`; classes use `UpperCamelCase`; methods and fields use `lowerCamelCase`. Prefer `const` constructors/widgets, and use `shadcn_ui` components (especially `ShadTable`) for new screens. Register dependencies in `lib/injection_container.dart` via `get_it`.
@@ -20,7 +21,7 @@ Each feature ships with unit tests (`*_test.dart`) living beside the source modu
 Commits follow the existing Superport convention: Korean imperative summaries with optional English technical nouns, e.g., `"대여 상세 테이블 정렬 수정"`. For PRs, include (1) a concise summary of user-visible impact, (2) screenshots or GIFs for UI changes, (3) linked issue or JIRA reference, and (4) verification notes (commands run, tests passing). Squash before merge unless release tagging requires history.
 
 ## Change Comment Guidelines
-- Document every change with a Conventional Commit style summary line: `type(scope): 요약`. Use Korean imperatives for the message body while keeping the scope in English (module/package).
+- Document every change with a Conventional Commit style summary line: `type(scope): <summary in Korean>`. Use Korean imperatives for the message body while keeping the scope in English (module/package).
 - Follow the summary with a blank line and bullet points that detail the concrete modifications, each starting with `- ` and phrased in past-tense or imperative sentences that mention impacted modules.
 - Include tests, scripts, and document updates in the bullet list so reviewers understand coverage.
 - When multiple subsystems change, group bullets logically (e.g., backend, frontend, docs) and keep each bullet under 120 characters.
@@ -35,7 +36,7 @@ Commits follow the existing Superport convention: Korean imperative summaries wi
 
 ## Architecture & Environment Notes
 Initialize environments via `.env.development` / `.env.production` and load them through `Environment.initialize()` before bootstrapping DI. New data sources should expose repository interfaces in `domain/` and rely on the shared `ApiClient` instance. Do not use mock data in the application; always call the real backend (staging/production as appropriate). If an endpoint is not available, mark the feature as disabled behind a feature flag rather than mocking.
-- Frontend behaviour/data models must strictly follow the deployed backend contract. (프론트엔드는 백엔드 API 계약을 절대 우선으로 준수해야 하며, 누락된 기능은 백엔드 수정 요청 후 진행한다.)
+- Frontend behaviour/data models must strictly follow the deployed backend contract. If a required endpoint is missing, request a backend fix rather than introducing mock data.
 
 ---
 
@@ -51,7 +52,9 @@ Initialize environments via `.env.development` / `.env.production` and load them
 
 ## Notification Policy
 
-- Every task completion must trigger a notification via the configured `notify.py` workflow so users are consistently alerted.
+- Run `notify.py` right before delivering the final wrap-up report or ending the conversation so the notification is sent at task completion.
+- Use the `notify.py` script located at `/Users/maximilian.j.sul/.codex/notify.py`.
+- Update relevant progress documents when a task is completed (e.g., `doc/approval_flow_frontend_task_plan.md`).
 
 ---