backfill-issue-state batches 50 ids into getByIds but Vectorize caps it at 20

[liplus-lin-lay]

目的

/admin/backfill-issue-state が Vectorize の getByIds 制限を超えた batch を送って失敗する状態を直す。#209 の修復が大きい repo で完了できない。

確認済みの事実（2026-08-03 本番実行）

#212 merge / deploy 後、索引対象 6 repo に対して backfill を実行した結果:

repo	結果
Liplus-Project/liplus-language	VECTOR_GET_ERROR (code = 40007): too many ids in payload; max id count is 20, got 50
Liplus-Project/github-rag-mcp	同 ... max id count is 20, got 22
Liplus-Project/github-webhook-mcp	成功（stale 20 / 全て反映）
Liplus-Project/liplus-desktop	成功（stale 2）
Liplus-Project/dipper_ai	成功（stale 0）
Liplus-Project/neuron-graph-rag	成功（stale 0）

src/backfill-issue-state.ts の VECTOR_BATCH_SIZE = 50。コメントは「documented 1000-vector batch cap の十分内側」と述べているが、1000 は upsert 側の上限であり、getByIds の上限は 20（上記エラーが返す実測値）。stale が 20 を超える repo で必ず落ちる。成功した 4 repo は stale が 20 以下だったため到達しなかった。

部分修復は発生していない。 dense を sparse より先に書く設計どおり、最初の getByIds batch で throw して D1 に触れる前に呼び出し全体が失敗している。失敗した 2 repo の search_docs は未変更のまま。

制約

• upsert 側は 20 でも問題ない（現状 batch size は get / upsert 共通の 1 定数）。get の制限に合わせれば両方満たす。
• 修正後、失敗した 2 repo（liplus-language / github-rag-mcp）に対して backfill を再実行すること。冪等なので成功済み repo への再実行も無害。

対象ファイル

• src/backfill-issue-state.ts（VECTOR_BATCH_SIZE とその根拠コメント）
• 回帰テスト（既存の「batch して 1 行 1 call にしない」テストが 50 前提なら合わせる）

背景

#209 の backfill を本番実行して判明した。#212 の self-review では定数のコメントが挙げる根拠を検証せず受け入れており、実行して初めて出た。