/dw reload` の完全リロード処理を実装したい（Manager乱立による保守性低下）

[RuskLabo]

背景

現状の /dw reload は一部の機能（例: SkilltreeGUI.reload()）しか更新しておらず、Deepwither 全体の状態を安全に再初期化できません。

Deepwither には多数の Manager / Service が存在しており、各所に個別リロード処理が分散しているため、以下の問題が発生しています。

• リロード対象漏れが起こりやすい
• 実行順依存（Aの後にBを再読込しないと壊れる）が暗黙化している
• 失敗時のロールバック/部分復旧ができない
• 将来の Manager 追加時に /dw reload へ反映忘れが起きる

---

現状の課題

• /dw reload が「全体リロード」の期待に対して実態が追いついていない
• Managerごとに API が不統一（reload(), load(), init(), reset() など）
• 依存関係がコード上で明示されておらず、順序保証ができない
• リロードの進行状況/失敗箇所が管理者に見えない
• 非同期タスクやキャッシュ、Listener の再登録境界が曖昧

---

提案

1) Reload Orchestrator の導入

ReloadManager（仮称）を新設し、/dw reload は必ずここを経由する。

• 役割:
  • リロード対象コンポーネントの一元登録
  • 依存関係を考慮した順序制御（トポロジカルソート等）
  • 実行結果の集約（成功/失敗/所要時間）
  • フェーズ実行（preReload → reload → postReload）

2) 共通インターフェースの定義

既存 IManager を拡張 or Reloadable を追加。

public interface Reloadable {
    String id();
    List<String> dependsOn();
    void preReload(ReloadContext ctx) throws Exception;
    void reload(ReloadContext ctx) throws Exception;
    void postReload(ReloadContext ctx) throws Exception;
}

3) 失敗戦略の明確化

/dw reload の実行モードを分離:

• strict（デフォルト）: 1つでも失敗したら停止してエラー返却
• best-effort: 失敗を記録しつつ継続

4) 可観測性の追加

• 管理者向けにチャット/コンソールへ進捗表示
• どの Manager が何msかかったか出力
• 失敗時にスタックトレース要約 + 次アクション提示

---

完了条件（Acceptance Criteria）

• /dw reload で全登録Managerが統一フローで再読込される
• 依存順が保証され、順序バグが再現しない
• 失敗時に「どのコンポーネントが」「なぜ失敗したか」が分かる
• 新規Manager追加時、Orchestrator登録のみで reload 対応可能
• 既存の主要機能（スキル、ダンジョン、クエスト、マーケット等）が reload 後も継続動作する

---

実装タスク案

• Reloadable / ReloadContext / ReloadResult の追加
• ReloadManager 実装（依存解決 + フェーズ実行 + ログ集約）
• /dw reload を ReloadManager 経由へ置換
• 既存主要Managerを段階的に Reloadable 対応
• strict / best-effort モード切替の実装
• リロード統合テスト（最低: 順序・失敗時挙動・結果出力）

---

懸念点 / 注意事項

• Listener の二重登録に注意（reload 前後で unregister/register を明示）
• 非同期タスクが古い参照を掴み続けないよう停止・再起動境界を設計
• DB接続やキャッシュ再利用方針（再接続/再生成）を統一
• リロード中のプレイヤー操作をどう扱うか（ロック or 警告のみ）を決める

---

参考（現行挙動）

DeepwitherCommand の reload サブコマンドは現在、メッセージ送信後に SkilltreeGUI.reload() を呼ぶのみで、全体再初期化の入口としては不十分。