feat(joinir): Phase 33-22 CommonPatternInitializer & JoinIRConversionPipeline integration

Unifies initialization and conversion logic across all 4 loop patterns,
eliminating code duplication and establishing single source of truth.

## Changes

### Infrastructure (New)
- CommonPatternInitializer (117 lines): Unified loop var extraction + CarrierInfo building
- JoinIRConversionPipeline (127 lines): Unified JoinIR→MIR→Merge flow

### Pattern Refactoring
- Pattern 1: Uses CommonPatternInitializer + JoinIRConversionPipeline (-25 lines)
- Pattern 2: Uses CommonPatternInitializer + JoinIRConversionPipeline (-25 lines)
- Pattern 3: Uses CommonPatternInitializer + JoinIRConversionPipeline (-25 lines)
- Pattern 4: Uses CommonPatternInitializer + JoinIRConversionPipeline (-40 lines)

### Code Reduction
- Total reduction: ~115 lines across all patterns
- Zero code duplication in initialization/conversion
- Pattern files: 806 lines total (down from ~920)

### Quality Improvements
- Single source of truth for initialization
- Consistent conversion flow across all patterns
- Guaranteed boundary.loop_var_name setting (prevents SSA-undef bugs)
- Improved maintainability and testability

### Testing
- All 4 patterns tested and passing:
  - Pattern 1 (Simple While): ✅
  - Pattern 2 (With Break): ✅
  - Pattern 3 (If-Else PHI): ✅
  - Pattern 4 (With Continue): ✅

### Documentation
- Phase 33-22 inventory and results document
- Updated joinir-architecture-overview.md with new infrastructure

## Breaking Changes
None - pure refactoring with no API changes

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

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

docs/development/current/main/phase170-completion-report.md

@@ -302,3 +302,77 @@ Phase 170 successfully prepared the environment for JsonParserBox validation and
 - ✅ Clear next steps with 5-hour implementation estimate
 
 **Next Step**: Implement Phase 171 - Condition Variable Extraction for Boundary Mapping.
+
+---
+
+## Phase 170‑C‑1: CaseA Shape 検出の暫定実装メモ
+
+Phase 170‑C‑1 では、当初「LoopUpdateAnalyzer (AST) → UpdateExpr を使って Generic 判定を減らす」方針だったが、
+実装コストと他フェーズとの依存関係を考慮し、まずは **carrier 名ベースの軽量ヒューリスティック** を導入した。
+
+### 現状の実装方針
+
+- `CaseALoweringShape::detect_from_features()` の内部で、LoopFeatures だけでは足りない情報を
+  **carrier 名からのヒント** で補っている:
+  - `i`, `e`, `idx`, `pos` など → 「位置・インデックス」寄りのキャリア
+  - `result`, `defs` など → 「蓄積・結果」寄りのキャリア
+- これにより、`Generic` 一択だったものを簡易的に:
+  - StringExamination 系（位置スキャン系）
+  - ArrayAccumulation 系（配列への追加系）
+  に二分できるようにしている。
+
+### 限界と今後
+
+- これはあくまで **Phase 170‑C‑1 の暫定策** であり、箱理論上の最終形ではない:
+  - 変数名に依存しているため、完全にハードコードを排除できているわけではない。
+  - 真に綺麗にするには、LoopUpdateAnalyzer / 型推定層から UpdateKind や carrier 型情報を LoopFeatures に統合する必要がある。
+- 今後のフェーズ（170‑C‑2 以降）では:
+  - `LoopUpdateAnalyzer` に `UpdateKind` の分類を追加し、
+    - `CounterLike` / `AccumulationLike` 等を LoopFeatures に持たせる。
+  - 可能であれば carrier の型（String / Array 等）を推定する軽量層を追加し、
+    `CaseALoweringShape` は **名前ではなく UpdateKind/型情報だけ** を見て判定する方向に寄せていく。
+
+この暫定実装は「Phase 200 での loop_to_join.rs ハードコード削除に向けた足場」として扱い、
+将来的には carrier 名依存のヒューリスティックを段階的に薄めていく予定。
+
+---
+
+## Phase 170‑C‑2b: LoopUpdateSummary 統合（実装メモ）
+
+Phase 170‑C‑2b では、LoopUpdateSummaryBox を実コードに差し込み、  
+CaseALoweringShape が直接 carrier 名を見ることなく UpdateKind 経由で判定できるようにした。
+
+### 実装ポイント
+
+- 既存の `LoopUpdateSummary` 型を活用し、`LoopFeatures` にフィールドを追加:
+
+```rust
+pub struct LoopFeatures {
+    // 既存フィールド …
+    pub update_summary: Option<LoopUpdateSummary>, // ← new
+}
+```
+
+- `CaseALoweringShape` 側に `detect_with_updates()` を追加し、
+  `LoopUpdateSummary` 内の `UpdateKind` を見て形を決めるようにした:
+
+```rust
+match update.kind {
+    UpdateKind::CounterLike       => CaseALoweringShape::StringExamination,
+    UpdateKind::AccumulationLike  => CaseALoweringShape::ArrayAccumulation,
+    UpdateKind::Other             => CaseALoweringShape::Generic,
+}
+```
+
+- `loop_to_join.rs` では、まず `detect_with_updates()` を試し、  
+  それで決まらない場合のみ従来のフォールバックに流す構造に変更。
+
+### 効果と現状
+
+- carrier 名に依存するロジックは `LoopUpdateSummaryBox` の内部に閉じ込められ、  
+  CaseALoweringShape / loop_to_join.rs からは UpdateKind だけが見える形になった。
+- 代表的な ループスモーク 16 本のうち 15 本が PASS（1 本は既知の別問題）で、  
+  既存パターンへの回帰は維持されている。
+
+この状態を起点に、今後 Phase 170‑C‑3 以降で `LoopUpdateSummary` の中身（AST/MIR ベースの解析）だけを差し替えることで、  
+段階的に carrier 名ヒューリスティックを薄めていく計画。