fix(mir-builder): static method arity mismatch根治 - Phase 25.x

**問題**:
- ParserStmtBox.parse_using/4 に5引数が渡される
- me.method呼び出しで instance/static 判別なし
- static method に誤って receiver 追加

**修正**:
- MeCallPolicyBox: params[0]の型で instance/static 判別
- Instance method: receiver 追加
- Static method: receiver なし
- Arity検証（NYASH_ME_CALL_ARITY_STRICT=1）

**ドキュメント**:
- docs/reference/environment-variables.md 新規作成
- docs/development/architecture/mir-logs-observability.md 更新

**テスト**:
- src/tests/mir_stage1_cli_emit_program_min.rs 追加
- 既存 stage1 テスト全てパス

Phase: 25.x

docs/development/runtime/cli-hakorune-stage1.md

@@ -17,6 +17,10 @@ Status: design-only + Stage0 stub 実装済み（Phase 25.1 時点では仕様
   - Stage1 実行時は「CLI として」ではなく、これらのランタイムサービス層（C-ABI/extern）として利用することを前提とする。
   - Phase 25.1 現在は、Rust Stage0 から `.hako` 側 stub CLI（`lang/src/runner/stage1_cli.hako`）を子プロセスとして起動する
     ブリッジ（`src/runner/stage1_bridge.rs`）のみ実装済みで、自己ホスト EXE（`target/selfhost/hakorune`）はまだ設計段階。
+    - ブリッジは env-only 仕様で Stage1 stub を呼び出し、`STAGE1_EMIT_PROGRAM_JSON` / `STAGE1_EMIT_MIR_JSON` / `STAGE1_BACKEND`
+      / `STAGE1_SOURCE` などの環境変数をセットする。
+    - Stage‑1 UsingResolver は `HAKO_STAGEB_APPLY_USINGS=0` を既定とし、CLI 経路では prefix 連結を行わない（using 解決の検証は
+      専用テストで行い、CLI 本線は Program(JSON) 生成に集中させる）。
 - Stage1（Hakorune selfhost CLI）
   - 実体: `target/selfhost/hakorune`（Phase 25.1 では Ny Executor プロトタイプ）。
   - 役割: `.hako → Program(JSON) → MIR(JSON) → 実行/EXE` というパイプラインの制御。
@@ -229,6 +233,35 @@ hakorune emit mir-json [-o <out>] [--quiet] <source.hako>
   - `tools/selfhost/run_stage1_cli.sh --bin /tmp/hakorune-dev emit program-json apps/tests/minimal.hako` は exit code 0 だが stdout が空のまま。Stage‑B 側で box 定義を Program(JSON) に含められるようになるまで、Rust CLI / BuildBox (`tools/hakorune_emit_mir.sh`) 経由での JSON 取得を継続する。
   - using 解決は Stage0（Rust Runner）と Stage1（Hakorune）の二系統に分離する方針。Stage1 側は `lang.compiler.entry.using_resolver_box` で `nyash.toml` の `[modules]` を参照し、`HAKO_STAGEB_MODULES_LIST`（shell 側で生成した `name=path` リスト）をキーに依存 Box を text merge する。Rust 側は既存の Runner using 実装を維持し、Stage1 経路はこの Box で独立した自己ホスト導線を持つ。
 
+### Stage‑1 CLI デバッグメモ（Stage1Cli + BuildBox + ParserBox）
+
+- 中間スモーク: `apps/tests/stage1_cli_emit_program_min.hako`
+  - 役割: `Stage1Cli.emit_program_json` → `BuildBox.emit_program_json_v0` → `ParserBox.parse_program2` までを、Rust ブリッジや Stage0 runner を経由せずに直接 VM 上で実行する最小ケース。
+  - 実行例:
+    ```bash
+    NYASH_PARSER_STAGE3=1 HAKO_PARSER_STAGE3=1 \
+    NYASH_ENABLE_USING=1 HAKO_ENABLE_USING=1 \
+    ./target/release/hakorune apps/tests/stage1_cli_emit_program_min.hako
+    ```
+- Rust テスト側のハーネス: `src/tests/mir_stage1_cli_emit_program_min.rs`
+  - `include_str!("../../lang/src/runner/stage1_cli.hako")` で Stage1Cli 本体をバンドルし、`static box Main` を末尾に付けて 1 ソースとしてパースする形に統一。
+  - `mir_stage1_cli_emit_program_min_compiles_and_verifies`:
+    - Stage1Cli + UsingResolver + BuildBox を含んだモジュールが MIR 生成・verify まで通ることを確認（SSA/PHI 崩壊なし）。
+  - `mir_stage1_cli_emit_program_min_exec_hits_type_error`:
+    - VM 実行まで進め、Stage‑1 CLI 経路がまだ決定的に失敗すること（型エラー or 未解決呼び出し）が Rust テスト内で再現できることを確認するための箱。
+- 現時点で観測されている実行時エラー（2025‑11‑21 時点）:
+  - `apps/tests/stage1_cli_emit_program_min.hako` を直接 `hakorune` で実行すると、
+    - 以前の「String + Void」「String + MapBox」ではなく、
+    - `Type error: unsupported compare Ge on String("using \"foo/bar.hako\" as Foo\n") and Integer(19)`
+    - というエラーが Stage‑1 経路で発生している。
+  - 経路としては `Stage1Cli.emit_program_json` → `BuildBox.emit_program_json_v0` → `ParserBox.parse_program2` まで進んだうえで、
+    どこかで Compare(Ge) の両辺が String vs Int に崩れていることが確認できている。
+- デバッグ方針:
+  - Stage‑1 CLI 本線のバグ追跡は、必ず「小さな箱」から行う:
+    - `.hako` 側: `apps/tests/stage1_cli_emit_program_min.hako` で Stage1Cli+UsingResolver+BuildBox をまとめて叩く中間スモーク。
+    - Rust 側: `src/tests/mir_stage1_cli_emit_program_min.rs` で同じソースを `NyashParser → MirCompiler → VM` まで持ち込むテスト。
+  - 次フェーズでは、このハーネス上で Compare(Ge) 命令をスキャンし、「左オペランドがソース行 String、右が Int になっている Compare」を 1 関数単位まで特定し、その関数を別の minimal .hako + Rust テストに切り出して修正する。
+
 ## `check` コマンド（予約）
 
 ```text