env-sync: Vercel Custom Environment（staging 等）対応

[polidog]

要件

背景

env-sync の Vercel provider は環境変数の送信先環境として production / preview / development の 3 種のみ対応しており、Vercel の Custom Environment（例: staging）を environments に指定するとエラーになる。Custom Environment にも変数を同期できるようにする。

実装方針

• 対象ファイル: internal/provider/vercel/vercel.go（および必要に応じて config / i18n）
• entriesToVercelItems の validTargets バリデーションを見直し、production/preview/development 以外の値を「Custom Environment slug」として許容する。
• Vercel REST API では Custom Environment は target 配列ではなく customEnvironmentIds（env_* 形式の ID）で指定する必要がある。
  • GET /v9/projects/{idOrName}/custom-environments で slug → ID の対応を解決する（teamId 対応込み）。
  • item 構造体に customEnvironmentIds（json: "customEnvironmentIds", omitempty）を追加し、標準環境は従来どおり target に、Custom Environment は customEnvironmentIds に振り分けて送信本文へ含める。
• 指定された Custom Environment slug がプロジェクトに存在しない場合は分かりやすいエラーメッセージ（i18n 対応、en/ja 両カタログ）を返す。
• 標準環境（production/preview/development）と Custom Environment を同一エントリの environments に混在指定できること。
• 一覧表示（environments=... の表示）でも Custom Environment 名が確認できるようにする。
• README.md / README.ja.md および env-sync.yaml のコメントに Custom Environment 対応を追記する。

備考

• ターゲット解決は provider.Options / config.ResolveVercelTargets 経由（Token/ProjectID/TeamID）。既存の複数プロジェクト・vercel_project フィルタと整合させること。
• Custom Environment ID 解決は API 呼び出しを追加するため、既存の vercelFetchExistingKeys と同様に httptest でモックできる形にする。

完了条件

完了条件

• env-sync.yaml の environments に Custom Environment slug（例: [staging]）を指定した変数が、エラーにならず Vercel の該当 Custom Environment に同期される。
• 標準環境（production/preview/development）のみ指定した既存挙動が変わらない（後方互換）。
• production/preview/development と Custom Environment を混在指定（例: [production, staging]）した場合、標準環境は target、Custom Environment は customEnvironmentIds で正しく送信される。
• 存在しない Custom Environment slug を指定した場合、en/ja それぞれで分かりやすいエラーメッセージが出る。
• Custom Environment slug 解決の単体テスト、および混在指定の送信本文を検証するテストが追加され、go test ./... が通る。
• README.md / README.ja.md / env-sync.yaml のコメントに Custom Environment の指定方法が記載されている。

確認手順

• go build ./... && go test ./... が成功すること。
• internal/provider/vercel/vercel_test.go に httptest でモックした Custom Environment 解決・送信のテストが含まれ、パスすること。
• 手元検証（可能なら）: Custom Environment (staging) を持つ Vercel プロジェクトに対し
  1. env-sync.yaml に MY_KEY: { secret: true, environments: [staging] } を定義
  2. env-sync --env .env.production --dry-run で environments=[staging] が表示されること
  3. dry-run を外して実行し、Vercel ダッシュボードの staging 環境に MY_KEY が登録されることを確認
• 混在指定 [production, staging] でも production と staging 双方に登録されることを確認。

[polidog]

TDD 作業レポート

ステップ 1: Red — 失敗テストの作成

• Red: vercel_test.go に以下のテストを追加・変更
  • TestEntriesToVercelItems_CustomSlug_GoesToCustomEnvSlugs — staging が customEnvSlugs に振り分けられ Target に含まれない（既存の TestEntriesToVercelItems_InvalidEnvironment_Error を置換）
  • TestEntriesToVercelItems_MixedStandardAndCustom — [production, staging] 混在で Target/customEnvSlugs に正しく振り分け
  • TestVercelFetchCustomEnvironments_Success/HTTPError/NoTeamID — custom-environments API の呼び出し検証
  • TestApplyCustomEnvironments_NoCustomSlugs_NoAPICall — custom slug 0 件時に API を呼ばない
  • TestApplyCustomEnvironments_SlugNotFound_Error — 存在しない slug でエラー（slug 名含む）
  • TestApplyCustomEnvironments_Mixed_JSONBody — POST ボディに target + customEnvironmentIds が共存
• build failed: customEnvSlugs フィールドなし、vercelFetchCustomEnvironments/applyCustomEnvironments 未定義

ステップ 2: Green — 実装

• Green: 以下ファイルを変更して全テストが通過
  • internal/i18n/keys.go: MsgVercelCustomEnvNotFound/MsgVercelCustomEnvFetchFail/MsgVercelCustomEnvParseFail 追加、MsgVercelInvalidEnvironment 削除
  • internal/i18n/catalog_ja.go: 上記 3 キーの日本語定義追加、MsgVercelInvalidEnvironment 削除
  • internal/i18n/catalog_en.go: 上記 3 キーの英語定義追加、MsgVercelInvalidEnvironment 削除
  • internal/provider/vercel/vercel.go:
    • item struct に CustomEnvironmentIDs []string (omitempty) と customEnvSlugs []string（非公開）追加、Target に omitempty 追加
    • entriesToVercelItems: validTargets → Target、それ以外 → customEnvSlugs に振り分け（エラー返却なし）
    • vercelFetchCustomEnvironments: GET /v9/projects/{id}/custom-environments で slug→ID マップ返却
    • applyCustomEnvironments: customEnvSlugs を解決して CustomEnvironmentIDs を埋める（0 件は API 呼び出しなし）
    • Sync ループ: !opts.DryRun && tgt.Token != "" 条件下で applyCustomEnvironments を vercelFetchExistingKeys 前に呼ぶ
    • 一覧表示: Target + customEnvSlugs 結合で environments を表示

ステップ 3: Refactor

• なし（設計はシンプルなまま。メモ化キャッシュは計画どおり不採用）

ステップ 4: 検証

• lint: go vet ./... → エラーなし
• format: gofmt -l . → 差分なし（catalog ファイルは実装後に gofmt -w 適用済み）
• build: go build ./... → OK
• test: go test -race ./... → 全パッケージ PASS

[polidog]

PR: #41

[polidog]

実装・受け入れテスト完了。PR: #41

• 実装: Custom Environment slug の振り分け + GET /v9/projects/{id}/custom-environments による slug→ID 解決 + customEnvironmentIds 送信（混在対応・後方互換維持）
• code-quality: Critical 0（go vet / gofmt / build / test -race グリーン）
• 設計レビュー: Critical 0 / Warning 1（複数ターゲット時のエラー全体中止は意図的挙動として PR 設計メモに明記）
• Info 指摘 4 件（sort・重複ID・0件時メッセージ・パース失敗テスト）はすべて修正済み
• perf 静的解析: 指摘なし（ターゲットごと GET 1回・custom slug 未使用時は API 呼び出しゼロ）
• 受け入れテスト: 全項目 PASS（httptest モック + dry-run 検証。実 Vercel 環境での確認のみスキップ）
• Copilot レビュー: 1 ラウンド実施、指摘 0 件