fix(index): retry FTS write and delete failures on the next poll (doc, wiki, push)

[liplus-lin-lay]

#282 の修正です。

• 書き込み：doc / wiki の FTS5 upsert の失敗を握りつぶさず、upsert 全体を失敗にした。store の blobSha / contentHash は進まないので、次の poll でその資料をやり直す（doc は既存の failed > 0 による ETag 据え置きにそのまま乗る）
• 削除：cron の doc / wiki reap と push 経路の doc 削除で、store 記録は最後に、他の面がすべて消えたときだけ消す。reap の候補は store から読むので、記録が残れば次の run でやり直される
• doc の reap で部分失敗があった run は tree ETag を据え置く（Luna の指摘：進めると次の run が 304 で終わり、reap まで届かない）
• テスト：失敗した run では store が残ること、次の run でやり直して最後に store が消えることを、doc / wiki / push の各経路で確認した。embed-doc の失敗伝播テストも新しく追加した
• docs/0-requirements（英・日）の削除と ETag の節を更新した

#281 の全文索引には依存していません。

— Claude Lin

🤖 Generated with Claude Code

https://claude.ai/code/session_01GYtSBq9rYuBcTNmr473APb

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	github-rag-mcp	d64dd5b	Oct 13 2026, 08:45 AM

[liplus-lin-lay]

セルフレビュー（auto モード）

• 受け入れ条件：#282 の目的「更新・削除の途中で FTS だけが失敗しても、次の poll で回復する」を、doc / wiki / push の3経路それぞれで、失敗した run → 次の run でやり直し → store が最後に消える、という流れのテストで確かめた。doc では tree ETag の据え置きもテストで確かめた。CI（test / Workers Builds）は通過
• 範囲：#282 の対象ファイル一覧には webhook.ts（push 経路）が入っていなかったが、同じ穴があるため、規則を一つにそろえる目的の範囲内として含めた。issue / コメント側の削除（webhook.ts:228 など）は store 記録を持たない別の作りなので、今回は対象外とした
• 挙動の変化：Vectorize の削除だけが失敗した場合も store が残る。そのため、次の run で全部の面を消し直す（各面の削除は何度実行しても結果が同じなので害はない）
• wiki は ETag ではなく巡回するカーソルで動いているので、失敗したページは次にそのページまで巡回が来たときに拾い直される（すぐではなく、いずれ拾われる）
• ワークスペース側で後回しにした作業：なし
• 次の手順：squash merge

— Claude Lin