Use GitHub API conditional requests (ETag) to reduce idle polling subrequests #38

purpose

アイドル時のcronポーリングで発生するサブリクエスト数を削減する。
現状: 更新がなくても1リポジトリあたり3サブリクエスト/cron（GET watermark + GET GitHub API + POST watermark）。
5リポジトリ × 12回/時 × 24時間 = 約4,320サブリクエスト/日がアイドル時に空振りで発生している。

premise

• GitHub REST APIは条件付きリクエスト（If-None-Match / ETag）をサポートしている — 検証済み
• Issues APIエンドポイント（sinceパラメータ付き）が ETag を返すことを確認 — 検証済み
• 変更なしの場合 304 Not Modified が返り、レスポンスボディなし + APIレートリミット消費なし — 検証済み
• Cloudflare Workers の fetch() は If-None-Match を正しくオリジンに送るが、cache: "no-store" の指定が必要（Cloudflareキャッシュ層の干渉を防ぐ） — 検証済み
• ETag値をDurable Object (IssueStore) のwatermarkレコードに追加保存することで、次回リクエスト時に利用可能
• 304応答時はwatermarkの更新（POST）も不要 → 1リポジトリあたり3→2サブリクエストに削減

constraints

• fetchIssuePage に If-None-Match ヘッダ送信と304ハンドリングを追加
• fetch() に cache: "no-store" を指定してCloudflareキャッシュ層をバイパス
• 304応答時は pollRepo で早期リターン（watermark POST スキップ）
• ETagはページネーションの最初のページ（page=1）のみ保存・比較すれば十分
• 初回同期（watermarkなし）やETag未保存時は従来通り動作すること（後方互換）

target files

• src/poller.ts — fetchIssuePage にETagヘッダ追加 + cache: "no-store" + 304分岐、pollRepo に304早期リターン
• src/issue-store.ts — watermarkスキーマにetag フィールド追加