enhancement: mark_processed accepts one event per call, so consuming a PR's own events costs N round trips

[liplus-lin-lay]

目的

mark_processed が 1 イベント 1 呼び出ししか受けないため、AI 側の消費コストがイベント数に比例する。バッチ受付を足す。

前提

Li+ の運用規則（rules/operations/operations.md）で mark_processed は消費した全イベントに必須、かつ skills/operations-foreground-webhook-intake/SKILL.md で自己操作イベントは「溜めずに都度消す」と定められている。したがって省略や間引きは選択肢に無い。

一方、自己操作は 1 回の PR で 6〜10 イベントを生む（workflow_run の requested / in_progress / completed × 複数 workflow、pull_request_review、Cloudflare bot の issue_comment など）。

実測（2026-08-02、1 セッション）

github-rag-mcp #192 / #197 / #189 / #203 / #206、github-webhook-mcp #243 の 6 issue を処理した 1 セッションで、mark_processed を 7 バッチ・延べ 70 件強呼んだ。処理した「外部イベント」は 0 件で、全て自己操作の到達確認。

現行 tool set に bulk 版が無い（get_event / get_pending_status / get_webhook_events / list_pending_events / mark_processed）。

影響

• AI の context 消費: 1 件ごとに tool call と結果 JSON が積まれる。内容は {"success":true,"event_id":...,"purged":0} の繰り返しで、判断材料としての情報量はゼロ
• 往復数: バッチ内で並列に投げられるが、list_pending_events → 全件 mark_processed の 2 段が作業のたびに挟まる
• 取りこぼしの誘因: 件数が多いほど「後でまとめて」に流れやすく、これは skill が明示的に禁じている挙動

検討の材料

• mark_processed に event_ids: string[] を受ける形を足す（既存の単数 event_id は後方互換で残す）
• 別 tool mark_processed_bulk を足す
• filter 指定での一括消費（repo / type / before など）。強力だが誤って外部イベントを消す事故が起こりうるので、採るなら id 列挙より慎重な設計が要る

id 列挙型が素直。呼び出し側が list_pending_events の結果から選ぶ形は変わらず、消す対象を AI が明示的に選ぶという現行の安全性を保ったまま往復だけ畳める。

制約

• 既存の単数 event_id 呼び出しを壊さないこと
• 部分失敗の扱いを決めること（1 件失敗で全体を落とさない／どれが失敗したかを返す）
• MCP proxy の静的スキーマ更新が要る点に注意（新 param は再接続では反映されず npm 再公開が必要）

受け入れ条件

• 複数 id を 1 呼び出しで処理でき、成功／失敗が id 単位で返る
• 単数呼び出しの既存挙動が変わらないことがテストで固定されている
• 部分失敗時に成功分が確定していることがテストで固定されている