feat(phase-9.75g-0): Start BID-FFI type-first implementation strategy

- Create comprehensive type definitions for all future features
- Adopt FFI ABI v0 compliance with platform-aware pointers (usize)
- Implement 8-byte alignment for cross-platform compatibility
- Design single entry point: nyash_plugin_invoke
- Target Linux x86-64 for initial implementation
- Use unimplemented!() for gradual feature addition

Key decisions from AI review:
- Pointer width: platform-dependent (not fixed 32-bit)
- Early addition of Option/Result types
- Clear ownership rules for strings/arrays
- Extensible BoxHeader with magic number

Phase 9.75g-0: Build it simple, make it work, then extend!

local_tests/bid_design_consultation.txt

@@ -0,0 +1,73 @@
+Nyashプログラミング言語のBID（Box Interface Definition）設計についてご相談です。
+
+【背景】
+Nyashは「Everything is Box」哲学のプログラミング言語で、現在Phase 9.75fでビルトインBoxの動的ライブラリ化とBID統合プラグインアーキテクチャを実装中です。
+
+【現在の設計案】
+1. 基本BID定義（YAML形式）
+```yaml
+version: 1
+transport:
+  type: dynamic_library  # 将来: grpc, rest, wasm, python_bridge等
+  location: ./libnyash_file.so
+  
+interfaces:
+  - name: nyash.file
+    box: FileBox
+    methods:
+      - name: open
+        params: [{string: path}, {string: mode}]
+        returns: handle
+        effect: io
+```
+
+2. 統一接続層（Rust実装）
+```rust
+trait UniversalConnector {
+    fn connect(&self, bid: &BidDefinition) -> Result<Connection>;
+}
+
+// 各種コネクター実装
+struct DynamicLibraryConnector;  // C ABI/.so
+struct GrpcConnector;            // リモートサービス
+struct PythonBridgeConnector;    // Python統合
+```
+
+3. 将来の接続先
+- 他言語ライブラリ（Python/JS/Go/Java）
+- リモートサービス（REST/GraphQL/gRPC）
+- システムリソース（GPU/DB/MQ）
+- 未来技術（量子コンピューター等）
+
+【設計の狙い】
+- Protocol Agnostic: トランスポート層を抽象化
+- Location Transparent: ローカル/リモート透過的
+- Future Proof: 新技術追加が容易
+- Nyashコード不変: どんなバックエンドでも同じコード
+
+【懸念点と質問】
+1. **複雑性**: Transport抽象化は過度に複雑でしょうか？最初はC ABIのみに絞るべき？
+
+2. **型システム**: MirValueでの統一は現実的？各バックエンドの型差異をどう吸収？
+
+3. **性能**: 抽象化レイヤーのオーバーヘッドは許容範囲？特にタイトループでの呼び出し。
+
+4. **エラー処理**: 異なるトランスポート（ローカル/ネットワーク）のエラーを統一的に扱える？
+
+5. **段階的実装**: 以下の順序は妥当？
+   - Phase 1: C ABI動的ライブラリのみ
+   - Phase 2: REST/gRPC追加
+   - Phase 3: 言語ブリッジ（Python等）
+   - Phase 4: 汎用化
+
+6. **既存システムとの比較**: 
+   - WASM Component Model
+   - gRPC
+   - COM/CORBA
+   これらと比較してBIDの独自価値は？
+
+7. **セキュリティ**: Capability-based securityは必要？それとも過剰設計？
+
+実装者（Rust中級者）が理解・保守できる範囲で、将来の拡張性を確保する最適なバランスはどこでしょうか？
+
+プログラミング言語設計とFFI/プラグインシステムの専門的観点から、アドバイスをお願いします。

local_tests/bid_ffi_final_review.txt

@@ -0,0 +1,80 @@
+Nyashプログラミング言語のBID-FFI ABI v0統合計画について、最終レビューをお願いします。
+
+【背景】
+- Phase 9.75g BID（Box Interface Definition）が野心的すぎて複雑
+- 既存のFFI ABI v0仕様はシンプルで実績がある
+- 両者を統合し、段階的に実装可能な設計にしたい
+
+【統合計画の要点】
+
+1. **Phase 9.75g-0: FFI ABI v0準拠（1週間）**
+   - 型システム完全化：i32, i64, f32, f64, bool, string, array(T)
+   - メモリモデル明確化：32ビットポインタ、4バイトアライメント
+   - Effect system：pure/mut/io/controlの4種類
+   - Box layout標準化：[type_id:i32][ref_count:i32][field_count:i32]
+
+2. **実装の簡素化戦略**
+   ```rust
+   // Phase 1: C ABIのみ
+   pub enum TransportType {
+       DynamicLibrary,      // 最初はこれだけ
+       #[allow(dead_code)]
+       Grpc,               // Phase 2で追加
+       Rest,               // Phase 2で追加
+       WasmComponent,      // Phase 3で追加
+   }
+   ```
+
+3. **文字列・配列の統一表現**
+   ```rust
+   // FFI ABI v0準拠
+   BidType::String => vec![WasmType::I32, WasmType::I32], // (ptr, len)
+   BidType::Array(_) => vec![WasmType::I32, WasmType::I32], // (ptr, len)
+   ```
+
+4. **段階的拡張パス**
+   - Phase 1: ローカルC ABI（.so/.dll）のみ
+   - Phase 2: ネットワーク対応（gRPC/REST）
+   - Phase 3: 言語ブリッジ（Python等）
+   - Phase 4: 未来技術対応（量子等）
+
+【設計原則】
+- **Simple First**: 動くものを最速で作る
+- **FFI ABI v0互換**: 実績ある仕様に準拠
+- **拡張可能**: TransportTypeで将来対応を予約
+- **Everything is Box**: Nyash哲学を維持
+
+【質問】
+
+1. **FFI ABI v0準拠は適切か？**
+   - 型システムの統合方針は妥当か？
+   - メモリモデル（32ビット、4バイトアライメント）は現実的か？
+   - WASMとネイティブの両対応は可能か？
+
+2. **段階的実装は現実的か？**
+   - Phase 1でC ABIのみに絞るのは賢明か？
+   - vtableを後回しにして基本型のみから始めるのは？
+   - 1週間でFFI ABI v0準拠は達成可能か？
+
+3. **拡張性は確保されているか？**
+   - UniversalConnectorトレイトは将来のgRPC/REST対応に十分か？
+   - BidTypeは将来の複雑な型（Future/Stream等）に対応できるか？
+   - エラーモデルは異なるトランスポートに対応可能か？
+
+4. **実装の落とし穴は？**
+   - 文字列の(ptr, len)表現で注意すべき点は？
+   - Box layoutのプラットフォーム依存性は？
+   - 既存のNyashコードとの互換性維持は？
+
+5. **NyaMesh（P2Pライブラリ）との整合性**
+   - 将来P2P通信もBIDで統一できるか？
+   - TransportTypeにP2Pを追加する価値は？
+   - 場所透過性の設計は適切か？
+
+【期待する成果】
+- 1週間で動くC ABIプラグインシステム
+- WASM/VM/LLVMすべてで同じBIDが使える
+- 将来のネットワーク対応への明確な道筋
+- Everything is Box哲学の技術的実現
+
+実装者（Rust中級者）が理解でき、確実に動作し、将来拡張可能な設計になっているか、専門的観点からレビューをお願いします。

local_tests/mir_output.txt

@@ -0,0 +1,15 @@
+🚀 Nyash MIR Compiler - Processing file: local_tests/test_simple_string.nyash 🚀
+🔍 build_new_expression: class=StringBox, arguments=[Literal { value: String("Hello"), span: Span { start: 0, end: 0, line: 1, column: 1 } }]
+🔍 build_new_expression: StringBox with literal string: "Hello"
+🚀 MIR Output for local_tests/test_simple_string.nyash:
+; MIR Module: main
+
+define void @main() {
+bb0:
+    0: safepoint
+    1: %0 = const "Hello"
+    2: %1 = ref_new %0
+    3: ret %1
+}
+
+

local_tests/trace_mir_gen.nyash

@@ -0,0 +1,6 @@
+// Trace MIR generation
+static box Main {
+    main() {
+        print("Hello")
+    }
+}