feat(phase32): L-2.1 Stage-1 UsingResolver JoinIR integration + cleanup

Phase 32 L-2.1 complete implementation:

1. Stage-1 UsingResolver main line JoinIR connection
   - CFG-based LoopForm construction for resolve_for_source/5
   - LoopToJoinLowerer integration with handwritten fallback
   - JSON snapshot tests 6/6 PASS

2. JoinIR/VM Bridge improvements
   - Simplified join_ir_vm_bridge.rs dispatch logic
   - Enhanced json.rs serialization
   - PHI core boxes cleanup (local_scope_inspector, loop_exit_liveness, loop_var_classifier)

3. Stage-1 CLI enhancements
   - Extended args.rs, groups.rs, mod.rs for new options
   - Improved stage1_bridge module (args, env, mod)
   - Updated stage1_cli.hako

4. MIR builder cleanup
   - Simplified if_form.rs control flow
   - Removed dead code from loop_builder.rs
   - Enhanced phi_merge.rs

5. Runner module updates
   - json_v0_bridge/lowering.rs improvements
   - dispatch.rs, selfhost.rs, modes/vm.rs cleanup

6. Documentation updates
   - CURRENT_TASK.md, AGENTS.md
   - Various docs/ updates

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

docs/development/roadmap/README.md

@@ -6,6 +6,7 @@
 - **現在のタスク**: [../../CURRENT_TASK.md](../../CURRENT_TASK.md)
 - **Phase 8.3**: Box操作WASM実装（Copilot担当）
 - **Phase 8.4**: ネイティブコンパイル実装計画（AI大会議策定済み）
+- **Stage‑1 / JSON v0**: Stage‑1 CLI minimal は Program(JSON v0) まで安定到達済み、Ny compiler 経路の JSON v0→MIR 統一は Phase 28.2 以降で追う
 
 ## 🚀 ネイティブコンパイル計画 (2025-08-14策定)
 

docs/development/roadmap/phases/phase-25.1/span-trace.md

@@ -3,3 +3,5 @@
 - 方針: MIR 命令に AST Span を持たせ、VMError (StepBudgetExceeded) で fn/bb/inst に加えて .hako 行番号を出す。
 - 実装: MirInstruction 生成時に current_span を保存し、VM 側で last_inst_idx から Span を引いてエラーに埋め込む。Span が無い場合は従来どおり fn/bb/inst のみ。
 - 状態: Stage‑1 CLI の MIR には Span 未付与なので行番号はまだ出ていないが、Span 付き MIR なら `... (file.hako:line:col)` まで表示できる。
+- ダンプ: `RUST_MIR_DUMP_PATH=/tmp/foo.mir` を指定すると、VM 実行前の MirModule をファイルに出力できる（`--dump-mir` のファイル版）。Stage‑1/Stage‑B 経路でも共通で使う想定。
+- JSON v0 経路: `json_v0_bridge::maybe_dump_mir` が Program(JSON v0)→MIR 直後に動くので、Span が付いていればそこで観測できる（AST 直通の MirPrinter dump では Span 表示なし）。

docs/development/roadmap/phases/phase-25.1/stage1-cli-loop-analysis.md

@@ -4,7 +4,7 @@
 - `Stage‑1 CLI → BuildBox.emit_program_json_v0` 実行時に VM が step budget を食い尽くしている原因を、  
   ループ構造と BoxCall 依存の観点から整理しておくためのメモだよ。
 
-## 1. 観測された症状
+## 1. 観測された症状（修正前スナップショット）
 
 - コマンド例:
   ```bash
@@ -13,12 +13,22 @@
   STAGE1_EMIT_PROGRAM_JSON=1 \
   ./target/release/hakorune apps/tests/minimal_ssa_skip_ws.hako
   ```
-- 状態:
+-- 状態（修正前）:
   - `[stage1-bridge/trace]` ＋ `[stage1-cli/debug] emit_program_json ENTRY` が出ており、  
     Stage1CliMain.main/0 〜 stage1_cli.hako 実行までは到達している。
   - その後 `BuildBox.emit_program_json_v0` 実行中に VM が `vm step budget exceeded`（max_steps=1_000_000→2_000_000 でも NG）。
   - FileBox/ArrayBox などの plugin 未ロード警告も併発。
-  - 現状は **ステップ上限＋プラグイン依存** が阻害要因となって、program-json 自体は得られていない。
+  - 当時は **ステップ上限＋プラグイン依存** が阻害要因となって、program-json 自体は得られていなかった。
+
+## 1.1 現在の状態（2025-11 時点）
+
+- ParserBox / StringHelpers / 各種 parser_* 箱のすべての  
+  `loop(cont == 1) { if cond { ... } else { cont = 0 } }` 形式のループを、
+  `loop(true) { if cond { ...; continue } break }` 形式に統一した。
+- 代表ループ（`parse_program2` 本体、ws_init、セミコロン消費、string/number/map/array/control/exception/stmt/expr 系ループ）を一括で MirBuilder-friendly な形に寄せた結果、
+  - `NYASH_USE_STAGE1_CLI=1 STAGE1_EMIT_PROGRAM_JSON=1 HAKO_VM_MAX_STEPS=2000000 NYASH_STAGE1_INPUT=apps/tests/minimal_ssa_skip_ws.hako ./target/release/hakorune`
+    で **step budget 超過無し**、Program(JSON v0) が `{"version":0,"kind":"Program","body":[]}` として出力されることを確認済み。
+  - VM の step budget エラーには fn/bb/last_inst ＋ Span（あれば .hako:line）が付くようになっており、将来の類似ケースも追いやすい。
 
 ## 2. emit_program_json_v0 周辺のループ構造（概観）