bug-investigation-to-issuelisted

# Bug Investigation to Issue 症状をIssueへ転記す���のではなく、第三者が再現・判断・修正できる証拠束へ変換する。 根拠が不足した観測は起票せず、`investigation_hold`として不足項目を返す。 ## 権限と境界 - 現在のユーザー依頼に「起票して」「Issue化して」など明示的な投稿意図がある場合だけ `live-file`とする。それ以外は`report-only`でIssue本文案まで作る。 - 調査はread-onlyを基本とし、製品コードの修正、commit、push、PR、既存Issueへの コメント・close・reopen・label変更を行わない。 - 既存Issueまたは修正中PRが同じ根本原因を扱う場合、新規Issueを作らずURLと対応関係を返す。 - 1根本原因につき1Issue。同じ原因が複数症状を生む場合は1件へまとめ、別原因は分ける。 - 1回の起票は最大5件。残件は証拠付き候補として報告し、無理に統合しない。 - 本番の送信、決済、削除、公開、顧客データ変更は再現に使わない。安全なfixture、隔離profile、 dry-run、read-only観測へ置き換えられなければ`blocked_safety`で止める。 - secret、token、cookie、認証header、個人情報、prompt/response全文、顧客データ、URL query、 secretを含み得る絶対pathをログ・成果物・Issueへ出さない。 ## 先に読む契約 1. 毎回 [調査・原因確定契約](references/investigation-contract.md) を読む。 2. 起票またはIssue本文案を作る段階で [GitHub Issue契約](references/github-issue-contract.md) を読む。 3. Sprint Coderの可視UI再現が必要な場合だけ`../sprint-coder-e2e-patrol/SKILL.md`を読む。 4. 指定範囲から候補を発見する必要がある場合だけ、静的調査には `../codebase-patrol/SKILL.md`、可視UI調査には`../sprint-coder-e2e-patrol/SKILL.md`を読む。 どちらもこの実行内では`report-only`の候補発見laneとして使い、Issue作成は本Skillの 原因確定・重複・秘匿gateを通過した後にだけ行う。 ## 実行フロー ### 1. Preflight 1. repository root、remote、current branch、full SHA、`git status --short`を実測する。 2. 対象に適用される`AGENTS.md`、仕様、受入条件、関連テスト、manifestを読む。 3. ユーザーの既存変更を記録し、調査中に上書きしない。 4. 症状、影響範囲、発生環境、観測時刻、期待値の出典を「確認済み」と「未確認」に分ける。 5. 現在の依頼から`live-file`か`report-only`かを固定する。 症状が提示されている場合は`symptom-led`、範囲だけが提示されている場合は`area-audit`とする。 `area-audit`では対象範囲と時間・件数の上限を固定し、静的、可視UI、または両方の発見laneを