chore: db/migration 의 legacy V001/V002 SQL 을 notes/ archive 로 이동

Flyway 가 V001 두 개 (기존 V001__create_ai_llm_providers + 새로 들어온 V001__varchar_migration) 를 충돌로 거부 → backend pod CrashLoopBackOff.
운영 schema 와 호환 검토 전까지 db/migration/ 밖으로 빼서 archive.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

notes/gbpark/2026-05-03-legacy-sql-archive/README.md

@@ -0,0 +1,21 @@
+# Legacy SQL 아카이브 (Flyway 충돌 회피)
+
+2026-05-03 backend-spring/src/main/resources/db/migration/ 에서 이쪽으로 옮겨온 SQL 두 개. 더이상 Flyway 자동 실행 대상 아님.
+
+## 옮긴 이유
+
+- 4/28 Johngreen 이 main 브랜치에 AI 모듈 V001~V016 추가 (`V001__create_ai_llm_providers.sql` 등)
+- 5/3 새벽 80cd2b2d0 커밋이 누락 untracked 파일 일괄 추가 시 본 두 파일이 같이 끌려들어가면서 V001/V002 중복 발생
+- Flyway 는 같은 버전 두 개면 부팅 fail (`Found more than one migration with version N`) → backend-spring 컨테이너 crash → 운영 다운 위험
+- 본 두 파일은 운영 DB 에 이미 도커 직접 실행으로 적용 완료된 1회성 마이그레이션이라, git 트리에서 빼는 대신 기록용으로 이쪽 보관
+
+## 파일
+
+| 파일 | 크기 | 내용 |
+|---|---|---|
+| `V001__varchar_migration.sql` | 70KB | 비-timestamp 숫자/boolean 컬럼 → VARCHAR 일괄 변환 (608 컬럼, FK 17개 drop/recreate) |
+| `V002__create_missing_tables.sql` | 2.9KB | booking_requests / mail_account_file / mail_template_file / open_api_proxy / work_history 5개 테이블 신규 생성 |
+
+## 다시 돌릴 일이 있다면
+
+새 환경(신규 테넌트 DB) 에 처음부터 적용해야 하는 상황이면, 파일명 V001/V002 prefix 를 떼고 `psql -f` 로 직접 돌리거나, AI V016 뒤 V017/V018 로 rename 해서 Flyway 체인에 다시 끼워넣기. 단 이 경우 `flyway_schema_history` 와 실제 DB 상태가 일치하는지 사전 확인 필수.