feat(llvm/phi): Phase 277 P1 - fail-fast validation for PHI strict mode

## Summary
Implemented fail-fast validation for PHI ordering and value resolution in strict mode.

## Changes

### P1-1: Strict mode for "PHI after terminator"
- File: `src/llvm_py/phi_wiring/wiring.py::ensure_phi`
- Behavior: `NYASH_LLVM_PHI_STRICT=1` → RuntimeError if PHI created after terminator
- Default: Warning only (no regression)

### P1-2: Strict mode for "fallback 0"
- File: `src/llvm_py/phi_wiring/wiring.py::wire_incomings`
- Behavior: Strict mode forbids silent fallback to 0 (2 locations)
  - Location 1: Unresolvable incoming value
  - Location 2: Type coercion failure
- Error messages point to next debug file: `llvm_builder.py::_value_at_end_i64`

### P1-3: Connect verify_phi_ordering() to execution path
- File: `src/llvm_py/builders/function_lower.py`
- Behavior: Verify PHI ordering after all instructions emitted
- Debug mode: Shows "✅ All N blocks have correct PHI ordering"
- Strict mode: Raises RuntimeError with block list if violations found

## Testing
✅ Test 1: strict=OFF - passes without errors
✅ Test 2: strict=ON - passes without errors (no violations in test fixtures)
✅ Test 3: debug mode - verify_phi_ordering() connected and running

## Scope
- LLVM harness (Python) changes only
- No new environment variables (uses existing 3 from Phase 277 P2)
- No JoinIR/Rust changes (root fix is Phase 279)
- Default behavior unchanged (strict mode opt-in)

## Next Steps
- Phase 278: Remove deprecated env var support
- Phase 279: Root fix - unify "2本のコンパイラ" pipelines

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

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

docs/development/current/main/design/edgecfg-fragments.md

@@ -146,12 +146,41 @@ Frag = { entry_block, exits: Map<ExitKind, Vec<EdgeStub>> }
 - 原則:
   - bridge pattern は **汎用化しない**（固定形SSOT + fixture/smoke で仕様を固定するだけ）。
   - 将来は `Frag/ExitKind` 合成側へ **吸収して削除**する前提で追加する。
-- 撤去条件（最低限）:
-  1. loop の EdgeCFG 実戦投入が 1 箇所以上済み（BasicBlockId 層で `Frag + emit_frag` を使っている）
-  2. bridge pattern の fixture が “Frag 合成経路” で PASS する
-  3. quick/integration の FAIL 位置が悪化しないことを確認済み
-- 撤去手順（最小）:
-  - router から bridge pattern を外す → fixture/smoke で PASS 維持 → ファイル削除
+
+### Bridge contract（テンプレ / SSOT）
+
+bridge pattern を追加する場合は、最低限この “撤去条件” を先に書く（書けないなら追加しない）。
+
+- **固定する fixture/smoke（SSOT）**
+  - fixture（最小）と smoke（integration）を必ず紐づける
+  - 「何が通れば撤去できるか」を machine-checkable にする
+- **置換先（吸収先）の SSOT がある**
+  - Pattern番号列挙の反対側に、必ず “吸収先” を書く（例: `Frag/ExitKind` 合成、もしくは emission 入口）
+  - 吸収先が未確定な場合でも “層” は確定させる（pattern層にロジックを増やさない）
+- **撤去条件（最低限）**
+  1. 置換先（吸収先）で同じ fixture/smoke が PASS する
+  2. bridge pattern 依存の分岐が router から消せる（最小差分で削除できる）
+  3. quick/integration の FAIL 位置が悪化しない（既知Failは増やさない）
+- **撤去手順（最小）**
+  - router から bridge pattern を外す
+  - fixture/smoke（+ quick）で PASS 維持
+  - ファイル削除（または historical へ隔離）し、SSOT から参照を外す
+
+### Phase 271: `Pattern9_AccumConstLoop` 撤去条件（SSOT）
+
+Phase 270 の “JoinIR-only minimal loop” を通すための橋渡し。将来は Frag 合成側へ吸収して削除する。
+
+- **固定 fixture/smoke**
+  - fixture: `apps/tests/phase270_p0_loop_min_const.hako`（exit=3）
+  - smoke: `tools/smokes/v2/profiles/integration/apps/phase270_p0_loop_min_const_vm.sh`
+- **吸収先（層）**
+  - Structured→CFG lowering 層（`Frag/ExitKind` 合成）またはその emission 入口（pattern層は extractor に縮退）
+- **撤去条件**
+  1. 上記 fixture/smoke が、bridge pattern を使わない経路で PASS する（Frag/emit_frag 側で loop を構築できる）
+  2. Pattern9 が router から削除されても coverage が落ちない（同 fixture が同じルートで通る）
+  3. `tools/smokes/v2/run.sh --profile quick` が悪化しない
+- **撤去手順**
+  - Pattern9 の router 分岐を削除 → smoke PASS → Pattern9 実装を削除（または historical 化）
 
 ## 実装入口（コード SSOT）