bug(webhook): the push-path doc delete lets a Vectorize failure strand the store row

[liplus-lin-lay]

目的

webhook の push 経路の doc 削除が、cron 側（#203 / PR #205 で修正済）と同じ非対称を残している。揃える。

前提

src/webhook.ts:490-515 の doc 削除ループは 1 件を 1 本の外側 try で包んでいる。

try {
  const dvid = await docVectorId(repo, path);
  await env.VECTORIZE.deleteByIds([dvid]);   // ← ここで throw すると
  try { await deleteFtsRow(...) } catch { ... }
  await storeStub.fetch(... DELETE /doc ...); // ← ここに到達しない
  deleted++;
} catch (err) { ... }

訂正（2026-08-02、PR #207 の実装時に実測）: 当初ここには「FTS5 だけ消えて store 行が残る」と書いていたが誤り。deleteFtsRow の内側 try は VECTORIZE.deleteByIds の後ろにあるため、Vectorize が throw した時点で外側 catch に飛び、D1 の 2 面はどちらも触られない。pre-fix 実装に対する実測で deleteFtsRow の呼び出しは 1 回ではなく 0 回。欠陥の所在と修正内容は変わらないが、取り残される範囲は当初の記述より広い。

cron 側（src/poller.ts の doc 削除ループ）は #203 で 3 面の独立 teardown に変えた。webhook 側は push イベントの一次経路であって cron はその fallback なので、実際に多く通るのはこちらの経路。

同ファイルの他の削除経路（issue/PR :228 付近、release :307 付近、comment :572 付近、review :660 付近、review comment :747 付近）は既に surface ごとに try が分かれている。doc 経路だけが取り残されている。

対象外（明示）

deleteEdgesForVector の追加は不要。doc_edges の端点は src / dst とも wiki vector ID で（indexWikiEdges が唯一の writer、index.ts の backfill も WHERE type = 'wiki_doc'）、doc vector ID は端点になりえない。0 行にしかマッチしない DELETE を将来仮定で足さない、というのが #203 の裁定。この不変条件が変わったら別途起票する。

制約

• 削除検出（push payload の removed）は変えない
• doc 以外の webhook 削除経路の既存挙動は変えない
• per-run cap は不要。webhook は 1 push あたりの件数が payload で決まっており、cron のように蓄積した集合を一度に舐める構造ではない（bug(docs): the doc reap has no per-run cap and its teardown is not surface-independent #203 の欠け 2 はこちらには当てはまらない）

受け入れ条件

• Vectorize の削除が失敗しても FTS5 行と store 行の teardown が実行されることがテストで固定されている
• 他の webhook 削除経路に変更が無い

想定変更箇所

• src/webhook.ts（doc 削除ループ）
• 対応するテスト

[liplus-lin-lay]

追記: deleted カウンタの意味を決めること

現行は 4 面すべて成功した時だけ deleted++ する構造（外側 try の末尾）。独立 teardown に変えると「一部失敗」が起こりうるので、レスポンスの deleted が何を数えるかを決める必要がある。

cron 側（src/poller.ts、#205 で merge 済）は removedDocs++ を teardown ループの直後に無条件で置き、試行した件数を数える形にした。webhook 側もこれに揃えるのが素直。揃えない場合は理由を PR 本文に残すこと。

受け入れ条件に 1 本追加:

• Vectorize が失敗したケースで、レスポンスの deleted の値がテストで固定されている（どちらの意味を採ったかが実装から読めること）