cli: config 組み立ての統一 (SimArgs→SimConfig→SimParams) と run/serve セットアップ重複の解消

[sksat]

設計レベルのコードベース調査(#95 の出発点)で挙がった候補。

現状

シミュレーション設定の組み立てが3モジュールに分散し、3段変換になっている:

• cli/src/cli.rs — 引数パース (SimArgs)
• cli/src/config.rs (1469行) — TOML/JSON/YAML デシリアライズ (SimConfig) + コマンド変換 (args_to_payload) が同居
• cli/src/sim/params.rs (875行) — 検証 + ランタイム変換 (SimParams)、TLE fetch、plugin backend 解決

問題点:

• plugin backend 解決が4箇所に分散 (cli.rs の enum / params.rs の解決ロジック / run.rs の override / serve/manager.rs の二次解決)
• orts.toml 自動検出が run.rs 内で暗黙的に行われる
• run.rs と serve/manager.rs が build_orbital_system() / third-body / integrator / space-weather セットアップをそれぞれ独立に再実装しており、片方だけ変えると挙動が割れる

方針(外部レビュー済み)

• SimParams の「純粋な解決」と「外部 I/O」を分離する。SimParams::from_config / from_sim_args 内に Epoch::now() や TLE fetch 等の副作用が混在しており、これがテスト困難の根因
• 解決後の SimulationPlan(どのモードでどう走らせるか)構築を1箇所に集約し、run/serve 双方がそれを使う
• 巨大な抽象 factory は作らない(orts/src/setup.rs に物理 model builder は既にある。足りないのは CLI 層の編成の一元化)
• plugin backend 解決を単一関数に集約。再現性のため resolved backend を log/recording に残す(auto threshold は実行環境依存のため)

検証

• 既存の cargo test -p orts-cli(E2E 含む)がそのまま通ること
• config は外部 contract なので、golden TOML/JSON のテストを足すと安全