症状
GitHub App liplus-webhook-mcp の webhook 配送が 全件失敗 している。
App → Advanced → Recent Deliveries が一律赤（Response 429、Completed in ~0.8s）。
直近 50 件 = 50/50 FAIL 、種別無関係（workflow_run.* / installation_repositories.added / pull_request_review.submitted すべて赤）。範囲 2026-06-21 14:27 JST → 現在。
結果、MCP get_pending_status が常時 pending_count: 0（イベントが保存されず intake が無音）。
根本原因（時刻ロックで確定的）
#230（fix(worker): constant-time signature verification, merge 2085f03, 2026-06-21 05:23:54Z ）で verifyGitHubSignature（worker/src/signature.ts）の署名比較を expected === signature → crypto.subtle.verify（定数時間）へ差し替え → 即デプロイ。配送失敗の起点 = 06-21 14:27 JST = 05:27 UTC = デプロイの 約4分後 。
Cloudflare ダッシュ: Worker は 213 リクエスト / CPU 3.2ms 。枠・プラン・量の問題ではない （無料枠にも何の上限にも届いていない）。コード回帰で確定。
#230 は「patch・機能契約は不変・観測変化なし」と宣言してマージされたが、実機の webhook は全弾落ちた 。79 テスト緑は proxy であって実機保証ではなかった（"動いてる挙動が正義"）。応答が 401/403 でなく 429 な点は、署名失敗の連発で rate-limit 系（#224 で導入）が二次的に発火した可能性。一次原因は fix(worker): constant-time signature verification (patch) #230
影響
webhook intake 全停止。2026-06-21 14:27 JST 以降の issue / PR / discussion / review イベントは未保存（取りこぼし）。
修正方針（候補）
即時復旧 = #230 を revert （gh pr revert 230）。webhook 即復旧＋因果確定。トレードオフ: #229 が塞いだ timing side-channel が一時的に後退（fix(worker): constant-time signature verification (patch) #230 fix-forward : 新 crypto.subtle.verify 経路のバグ特定（鍵 import / 生 32byte digest 復元 / sha256= prefix・64hex 形状検証あたりが濃厚）＋修正＋再デプロイ。side-channel 修正を保ったまま復旧。
推奨 = 1 で止血 → 2 で本筋。fix-forward 採否は実装者判断（この issue の唯一の未決点）。
対象ファイル
worker/src/signature.ts（実装の回帰）worker/test/signature.test.ts（実機配送形状での失敗を 79 緑が捕まえられなかった = 回帰テストの穴。GitHub 実配送 payload／実 header 形状でのケース追加）
確認
revert / fix 後、Recent Deliveries が緑（2xx）に戻ること ＋ get_pending_status に実イベントが入ること。
取りこぼし期間（06-21 14:27 JST 以降）の重要 delivery は Redeliver 検討（workflow_run は不要、issue_comment / pull_request_review 等のみ）。
別軸メモ: App は workflow_run を購読しているが intake 用途では不要。今回の原因ではないが、復旧後に購読を絞るとノイズが減る（別 issue 化可）。
occurrences
実機配送 50/50 fail（2026-06-22 目視確認、GitHub App Recent Deliveries + Cloudflare dashboard）。
症状
GitHub App
liplus-webhook-mcpの webhook 配送が 全件失敗している。Response 429、Completed in ~0.8s）。workflow_run.*/installation_repositories.added/pull_request_review.submittedすべて赤）。範囲 2026-06-21 14:27 JST → 現在。get_pending_statusが常時pending_count: 0（イベントが保存されず intake が無音）。根本原因（時刻ロックで確定的）
#230（fix(worker): constant-time signature verification, merge2085f03, 2026-06-21 05:23:54Z）でverifyGitHubSignature（worker/src/signature.ts）の署名比較をexpected === signature→crypto.subtle.verify（定数時間）へ差し替え → 即デプロイ。#230は「patch・機能契約は不変・観測変化なし」と宣言してマージされたが、実機の webhook は全弾落ちた。79 テスト緑は proxy であって実機保証ではなかった（"動いてる挙動が正義"）。#224で導入）が二次的に発火した可能性。一次原因は fix(worker): constant-time signature verification (patch) #230 の署名検証経路。要確認。影響
修正方針（候補）
#230を revert（gh pr revert 230）。webhook 即復旧＋因果確定。トレードオフ:#229が塞いだ timing side-channel が一時的に後退（fix(worker): constant-time signature verification (patch) #230 以前＝数ヶ月続いた状態、深刻度低）。crypto.subtle.verify経路のバグ特定（鍵 import / 生 32byte digest 復元 /sha256=prefix・64hex 形状検証あたりが濃厚）＋修正＋再デプロイ。side-channel 修正を保ったまま復旧。推奨 = 1 で止血 → 2 で本筋。fix-forward 採否は実装者判断（この issue の唯一の未決点）。
対象ファイル
worker/src/signature.ts（実装の回帰）worker/test/signature.test.ts（実機配送形状での失敗を 79 緑が捕まえられなかった = 回帰テストの穴。GitHub 実配送 payload／実 header 形状でのケース追加）確認
get_pending_statusに実イベントが入ること。workflow_runは不要、issue_comment/pull_request_review等のみ）。workflow_runを購読しているが intake 用途では不要。今回の原因ではないが、復旧後に購読を絞るとノイズが減る（別 issue 化可）。occurrences