reply-draftlisted

# reply-draft — 返信下書きを opshub に生成させる opshub の MCP write tool `propose.generate`（mode: `reply_to_source_id`、PR #231 で実装、`src/opshub/mcp/_registry.py` の `WriteCategory.PROPOSE_GENERATE`）と `propose.apply`（Phase 12 H1 で MCP に露出、`WriteCategory.PROPOSE_APPLY`、idempotent）を第一経路として返信下書きを作る。Phase 10 Sub-issue D で書き、Sub-issue E (#217 merged) で `ReplyDraftCandidatePayload` が実装済み。ADR-0016 §決定 (i)+(j)+(k) で吸収された。Phase 11 で Outlook body deep retention (#244 / ADR-0020 改���) が入り、`ms365_outlook` への reply-draft が本格機能化した（差出人の本文を full payload で context 注入できるようになった）。Phase 14 で Gmail (`gmail_message`、`google_mail` connector) が追加され、Outlook と symmetric な body 取得経路が成立したため、Gmail への reply-draft も同様に本格機能化した (ADR-0010 §改訂)。 pair: draft family (`handoff-draft` / `announcement-draft` と同族、ただし本 skill のみ persist する。返信元 source の有無で persist 境界が分かれる、ADR-0016 §決定 (l)(a))。 ## 何が起きるか 1. ユーザーが「これに返信下書き作って」「この slack に返信案」「メール返信どうする?」と頼む 2. ホストが本 skill を発火 3. ホストが対象の `source_id` を特定 (recall.search で source を引く or ユーザー入力) 4. MCP `propose.generate` (`reply_to_source_id` 指定) を呼んで `ProposalGenerated` event を発行 (HITL write tool) 5. 候補をホストがユーザーに提示、ユーザー確認後に MCP `propose.apply` で下書き保存（HITL、idempotent） 6. ユーザーが下書きを見て手で送信先 SaaS に貼り付ける opshub 側で外部 SaaS に直接投稿する経路は **存在しない** (ADR-0010 §禁止事項 7 + Sub-issue E test pin)。 ## 呼び出し順 ### Step 1: 返信元 source を特定 ユーザー入力に slack URL / メッセージ ID / GitHub issue 番号などがある場合はそれを使う。なければ recall で検索: ```text tool: recall.search input: query: "<返信したい相手 / トピック>" limit: 10 ``` `hits[]` から sou