docs(stage1): Phase 25.1 - Stage-1 CLI ValueId(34) SSA バグ完全調査完了

🔍 根本原因特定:
- 問題箇所: stage1_cli.hako:111 の args null チェックパターン
  local argc = 0; if args != null { argc = args.size() }

- 発生条件:
  1. 深い制御フロー（BasicBlockId(12266) = 12,266ブロック）
  2. using chain 複雑さ（BuildBox → ParserBox → 50+ファイル）
  3. 多段階早期return（複数の支配フロンティアとPHIマージ）

- なぜShapeテストは通るか:
  - スタブ実装（複雑な外部Box呼び出しなし）
  - 単一ファイル（using chain なし）
  - シンプルなCFG（数十ブロック vs 12,266ブロック）

✅ 解決策4案提示:
- Solution A: Fail-Fast Guard（最優先・最簡単）
  if args == null { args = new ArrayBox() }
  → PHI merge を 1定義に潰す

- Solution B: デバッグロジック抽出
  → 問題パターンを小さな関数に隔離

- Solution C: Rust Bridge修正
  → stage1_bridge.rs で常に非null保証

- Solution D: MIR Builder根治（長期）
  → SSA構築ロジック・PHI配置アルゴリズム改善

📋 成果物:
- 詳細調査レポート: docs/development/current/main/stage1_cli_ssa_valueid34_analysis.md
  - ValueId(34)の定義/使用ブロック解析
  - 呼び出しチェーン追跡
  - 制御フロー複雑度分析
  - 4つの解決策の詳細実装手順

- Shapeテスト追加: src/tests/stage1_cli_entry_ssa_smoke.rs
  - mir_stage1_cli_entry_like_pattern_verifies
  - mir_stage1_cli_stage1_main_shape_verifies
  - 構文とCFG形の正しさを検証（PASS）

🎯 技術的成果:
- MIRレベルのSSA追跡失敗メカニズムを完全解明
- 「テストは通るが実物は失敗」のギャップを構造的に特定
- 箱レベルでの実装可能な解決策を4案提示

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Task Assistant <task@anthropic.com>

src/tests/mod.rs

@@ -14,6 +14,7 @@ pub mod mir_loopform_conditional_reassign;
 pub mod mir_loopform_exit_phi;
 pub mod mir_loopform_complex;
 pub mod mir_stage1_using_resolver_verify;
+pub mod stage1_cli_entry_ssa_smoke;
 pub mod mir_stageb_like_args_length;
 pub mod mir_stageb_loop_break_continue;
 pub mod mir_value_kind; // Phase 26-A-5: ValueId型安全化統合テスト