feat(phi): Phase 25.1 - BTreeMap移行 (21ファイル、80%決定性達成)

## 修正内容

### Core MIR/PHI (5ファイル)
- builder.rs: variable_map, value_types, value_origin_newbox
- context.rs: 3つのマップ
- loop_builder.rs: 3箇所
- loop_snapshot_manager.rs: snapshot マップ
- loop_snapshot_merge.rs: 2箇所

### MIR関連 (4ファイル)
- function.rs: FunctionMetadata.value_types
- resolver.rs: CalleeResolverBox
- guard.rs: CalleeGuardBox
- loop_common.rs: apply_increment_before_continue

### JSON Bridge (5ファイル)
- json_v0_bridge/lowering.rs
- json_v0_bridge/lowering/expr.rs
- json_v0_bridge/lowering/if_else.rs
- json_v0_bridge/lowering/merge.rs
- json_v0_bridge/lowering/try_catch.rs
- json_v0_bridge/mod.rs

### Printer & Providers (4ファイル)
- printer.rs, printer_helpers.rs
- host_providers/mir_builder.rs
- backend/mir_interpreter/handlers/extern_provider.rs

### Tests (3ファイル)
- phi_core/conservative.rs
- tests/json_program_loop.rs
- tests/mir_stage1_using_resolver_verify.rs (2テスト有効化)

## テスト結果
- mir_stage1_using_resolver_resolve_with_modules_map_verifies: 80%成功率
- 完全な決定性は未達成 (HashMap 86箇所、HashSet 63箇所が残存)

🐱 Generated with Claude Code

docs/development/roadmap/phases/phase-25.1/README.md

@@ -22,6 +22,52 @@ Status: design+partial implementation（Stage1 ビルド導線の初期版まで
 
 ざっくりとした進行順は「25.1a/c で配線と箱分割 → 25.1d/e で Rust MIR/LoopForm を根治 → その結果を踏まえて 25.1b（selfhost MirBuilder/LoopSSA）側に寄せていく」というイメージだよ。
 
+## Legacy Loop/PHI 経路と削除方針（Phase 25.1 時点の整理）
+
+### 正系統（SSOT）として見るべき箱
+
+- ループまわりの SSOT:
+  - `src/mir/loop_builder.rs` … LoopForm v2 の構造的 lowering（header/body/latch/continue_merge/exit）。
+  - `src/mir/phi_core/header_phi_builder.rs` … header PHI（Pinned/Carrier）の宣言と seal 用メタデータ。
+  - `src/mir/phi_core/loop_snapshot_manager.rs` … continue/exit スナップショット管理と LoopSnapshotMerge への導線。
+  - `src/mir/phi_core/loop_snapshot_merge.rs` … preheader + continue_merge + latch + exit の snapshot を LoopForm 単位でマージする箱。
+- if/merge まわりの SSOT:
+  - `src/mir/builder/if_form.rs` … IfForm を用いた構造化 if lowering。
+  - `src/mir/phi_core/if_phi.rs` … if merge ブロックでの PHI 生成（ControlForm ベースのラッパを含む）。
+  - 今後: `BodyLocalPhiBuilder` を if-merge 側にも拡張して、BodyLocal 変数の PHI 判定を exit だけでなく body 内 if にも適用する予定（Phase 25.x/26.x で対応）。
+
+### Legacy 経路（新規利用禁止・将来削除予定）
+
+- `src/mir/phi_core/loop_phi.rs`
+  - 冒頭コメントどおり、LoopForm v2 + LoopSnapshotMergeBox への移行後は「legacy scaffold」としてのみ残存している。
+  - 現在の役割:
+    - 一部の dev/分析用ドキュメントや smokes から参照される互換レイヤ。
+    - 旧 LoopBuilder 互換 API（`prepare_loop_variables_with`, `seal_incomplete_phis_with`, `build_exit_phis_with` など）の受け皿。
+  - Phase 25.1 のポリシー:
+    - **新しいコードから `phi_core::loop_phi` を直接呼ばない**（LoopForm v2 系の箱のみを使う）。
+    - Legacy テスト／smoke のためにしばらく残すが、本線の PHI/SSA 設計の説明は LoopForm v2 系のファイルに寄せる。
+  - 削除条件（Phase 31.x 以降で実施予定）:
+    - すべての本線経路が `loopform_builder.rs` + `header_phi_builder.rs` + `loop_snapshot_merge.rs` に移行済みであること。
+    - `loop_phi.rs` を参照するのが「docs／analysis／legacy-smoke」のみになっていること。
+    - `docs/private/roadmap/phases/phase-31.2/legacy-loop-deletion-plan.md` に記載の条件（参照 0＋対応テスト移行）が満たされた時点で削除。
+
+### HashMap 利用の線引き（決定性の観点）
+
+- Phase 25.1 以降、**PHI／LoopForm／IfForm の決定性に関わるマップ**は次のルールに従う:
+  - 変数スナップショットや PHI 入力候補のように「順序が意味を持つ」構造:
+    - `BTreeMap` / `BTreeSet` / `Vec + sort_by_key` のいずれかを使用して、イテレーション順を決定的にする。
+    - 例:
+      - `MirBuilder::variable_map` / `value_types` / `value_origin_newbox` → `BTreeMap` 化済み。
+      - `phi_core::if_phi::compute_modified_names` → `BTreeSet` で変数名を収集したうえで決定的順序でマージ。
+  - メタ情報やインデックス（型とは無関係なキャッシュ・診断用データ構造など）:
+    - HashMap 維持可とし、「決定性には影響しない」ことをコメントで明記する。
+    - 例:
+      - `MirBuilder::weak_fields_by_box`, `property_getters_by_box`, `plugin_method_sigs` など。
+
+- 例外: `phi_core::loop_phi::sanitize_phi_inputs`
+  - 現在も内部で一度 `HashMap<BasicBlockId, ValueId>` に詰め替えた後 `Vec` に戻して `sort_by_key` しているため、出力順自体は決定的になっている。
+  - ただし、このユーティリティは **legacy 経路専用** と位置付けており、新しい LoopForm v2 系のコードでは `PhiInputCollector`（BTree ベース）側を SSOT として扱う。
+
 ## ゴール
 
 - Rust 製 `hakorune` を **Stage0 ブートストラップ**と位置付け、Hakorune コード（.hako）で構成された **Stage1 バイナリ**を明確に分離する。