feat(phase106): FileBox provider_lock整理 & Fail-Fast強化（案B統一版）

Task 1: CoreBoxId.category() 修正
- File を CoreRequired 側に移動（L126）
- テスト期待値修正（L371）
- Phase 106 intent コメント更新（L107-115）

Task 2: provider_lock API 確認
- 変更なし（既存の set/get API をそのまま使用）
- get_filebox_provider_strict() は追加しない（シンプルに保つ）

Task 3: FileBox SSOT コメント追加
- L5-7 に責務明示コメント追加

Task 4: PluginHost に FileBox provider チェック追加
- with_core_from_registry_optional() に Phase 106 チェック追加（L158-167）
- test_with_core_from_registry_filebox_required() 追加（L413-445）
- 既存テスト2件を FileBox provider 初期化対応（L301-321, L323-351）
- test_with_core_from_registry_missing_box() をエラーメッセージ拡張（L386-410）

Task 5: ドキュメント更新
- core_boxes_design.md に Phase 106 セクション追加（L248-265）
- 責務分離原則・Ring0.FsApi 延期を明記

完了条件:
✅ ビルド成功（cargo build --release）
✅ テスト全PASS（cargo test --lib runtime: 64 passed; 0 failed）
✅ 指示書の実装チェックリスト全て completed

AGENTS.md

@@ -297,8 +297,9 @@ fn check_layer_boundary() {
   - ランナー: `src/runner/modes/cranelift.rs`, `--jit-direct` は `src/runner/mod.rs`
 - 進行中の論点と手順は `CURRENT_TASK.md` を参照してね（最新のデバッグ方針・フラグが載ってるよ）。
 
-**PyVM 主経路（Phase‑15 方針）**
-- 主経路: Python/llvmlite + PyVM を標準の実行/検証経路として扱うよ。Rust VM/JIT は補助（保守/比較/プラグイン検証）。
+**PyVM ライン（Phase‑15 歴史メモ／現在は撤退済み）**
+> 注: 2025-12 現在、PyVM 実行経路は完全撤退中だよ。以下は Phase‑15 当時の方針と運用メモで、今は「歴史情報」としてだけ残しているよ。日常の開発・CI では Rust VM / LLVM ラインだけを使ってね。
+- 当時の主経路: Python/llvmlite + PyVM を標準の実行/検証経路として扱うよ。Rust VM/JIT は補助（保守/比較/プラグイン検証）。
 - 使い分け:
   - PyVM（推奨・日常確認）: `NYASH_VM_USE_PY=1 ./target/release/nyash --backend vm apps/APP/main.hako`
   - llvmlite ハーネス: `NYASH_LLVM_USE_HARNESS=1 ./target/release/nyash --backend llvm apps/APP/main.hako`
@@ -356,8 +357,9 @@ Notes
   - `NYASH_NY_COMPILER_CHILD_ARGS` → スペース区切りで子にそのまま渡す
 - 子側（apps/selfhost-compiler/compiler.hako）は `--read-tmp` を受理して `tmp/ny_parser_input.ny` を読む（plugins 必要）。
 
-## PyVM Scope & Policy（Stage‑2 開発用の範囲）
-- 目的: PyVM は「開発用の参照実行器」だよ。JSON v0 → MIR 実行の意味論確認と llvmlite とのパリティ監視に使う（プロダクション最適化はしない）。
+## PyVM Scope & Policy（Stage‑2 開発用の範囲・歴史メモ）
+> 注: このセクションも Phase‑15〜17 期の設計メモだよ。PyVM ラインは現在は撤退済みで、実行確認・CI は Rust VM / LLVM のみを対象にしているよ。
+- 目的: （当時）PyVM は「開発用の参照実行器」だよ。JSON v0 → MIR 実行の意味論確認と llvmlite とのパリティ監視に使う（プロダクション最適化はしない）。
 - 必須命令: `const/binop/compare/branch/jump/ret/phi`、`call/externcall/boxcall`（最小）。
 - Box/メソッド（最小実装）:
   - ConsoleBox: `print/println/log`
@@ -376,8 +378,9 @@ Notes
   - Bridge 短絡（RHS スキップ）: `tools/ny_stage2_shortcircuit_smoke.sh`
 - CI: `.github/workflows/pyvm-smoke.yml` を常時緑に維持。LLVM18 がある環境では `tools/parity.sh --lhs pyvm --rhs llvmlite` を任意ジョブで回す。
 
-## Interpreter vs PyVM（実行経路の役割と優先度）
-- 優先経路: PyVM（Python）を"意味論リファレンス実行器"として採用。日常の機能確認・CI の軽量ゲート・llvmlite とのパリティ監視を PyVM で行う。
+## Interpreter vs PyVM（実行経路の役割と優先度・歴史メモ）
+> 注: ここで言う「優先経路: PyVM」は Phase‑15 期のものだよ。現在は PyVM ラインは撤退済みで、Rust VM / LLVM を優先経路として扱うよ。
+- （当時の方針）優先経路: PyVM（Python）を"意味論リファレンス実行器"として採用。日常の機能確認・CI の軽量ゲート・llvmlite とのパリティ監視を PyVM で行う。
 - 補助経路: Rust の MIR Interpreter は純Rust単独で回る簡易器として維持。拡張はしない（BoxCall 等の未対応は既知）。Python が使えない環境での簡易再現や Pipe ブリッジの補助に限定。
 - Bridge（--ny-parser-pipe）: 既定は Rust MIR Interpreter を使用。副作用なしの短絡など、実装範囲内を確認。副作用を含む実行検証は PyVM スモーク側で担保。
 - 開発の原則: 仕様差が出た場合、llvmlite に合わせて PyVM を優先調整。Rust Interpreter は保守維持（安全修正のみ）。
@@ -386,8 +389,9 @@ Notes
 - Phase‑15 中は Rust VM/JIT への新規機能追加を最小化し、Python（llvmlite/PyVM）側での実装・検証を優先する。
 - Runner/Bridge は必要最小の配線のみ（子プロセスタイムアウト・静音・フォールバック）。意味論の追加はまず PyVM/llvmlite に実装し、必要時のみ Rust 側へ反映。
 
-## Self‑Hosting への移行（PyVM → Nyash）ロードマップ（将来）
-- 目標: PyVM の最小実行器を Nyash スクリプトへ段階移植し、自己ホスト中も Python 依存を徐々に縮小する。
+## Self‑Hosting への移行（PyVM → Nyash）ロードマップ（歴史メモ）
+> 注: このロードマップは「PyVM からの段階移行」を前提にした初期案だよ。現在は PyVM ライン自体が撤退しており、Rust VM / LLVM / Nyash 自己ホストの 3 本を前提に設計を進めているよ。
+- 目標: （当時の計画）PyVM の最小実行器を Nyash スクリプトへ段階移植し、自己ホスト中も Python 依存を徐々に縮小する。
 - ステップ（小粒度）:
   1) Nyash で MIR(JSON) ローダ（ファイル→構造体）を実装（最小 op セット）。
   2) const/binop/compare/branch/jump/ret/phi を Nyash で実装し、既存 PyVM スモークを通過。