Incremental improvements: mid_desc cache, pool hotpath optimization, and doc updates

**Changes:**
- core/box/pool_api.inc.h: Code organization and micro-optimizations
- CURRENT_TASK.md: Updated Phase MD1 (mid_desc TLS cache: +3.2% for C6-heavy)
- docs/analysis files: Various analysis and documentation updates
- AGENTS.md: Agent role clarifications
- TINY_FRONT_V3_FLATTENING_GUIDE.md: Flattening strategy documentation

**Verification:**
- random_mixed_hakmem: 44.8M ops/s (1M iterations, 400 working set)
- No segfaults or assertions across all benchmark variants
- Stable performance across multiple runs

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

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

docs/analysis/ENV_PROFILE_PRESETS.md

@@ -64,6 +64,7 @@ HAKMEM_SMALL_HEAP_V3_CLASSES=0x80   # C7-only v3, C6 v3 は OFF
 HAKMEM_POOL_V2_ENABLED=0
 HAKMEM_POOL_V1_FLATTEN_ENABLED=0    # flatten は初回 OFF
 ```
+- mid_desc_lookup TLS キャッシュを試すときだけ: `HAKMEM_MID_DESC_CACHE_ENABLED=1` を上乗せ（デフォルトは OFF）。
 
 ### Pool v1 flatten A/B 用（LEGACY 専用）
 ```sh
@@ -72,6 +73,21 @@ HAKMEM_TINY_HEAP_PROFILE=LEGACY
 HAKMEM_POOL_V2_ENABLED=0
 HAKMEM_POOL_V1_FLATTEN_ENABLED=1
 HAKMEM_POOL_V1_FLATTEN_STATS=1
+
+## Profile 2b: C6_HEAVY_LEGACY_POOLV1_FLATTEN（mid/smallmid LEGACY flatten ベンチ専用）
+
+### 目的
+- LEGACY プロファイルで mid/smallmid の flatten + header-only zero をまとめて opt-in するベンチ専用セット。
+- C7_SAFE では使わないこと（安定性優先のため C7_SAFE は flatten 常時 OFF）。
+
+### ENV（ベンチ専用）
+```sh
+HAKMEM_PROFILE=C6_HEAVY_LEGACY_POOLV1    # base を流用
+HAKMEM_POOL_V1_FLATTEN_ENABLED=1
+HAKMEM_POOL_ZERO_MODE=header
+HAKMEM_POOL_V1_FLATTEN_STATS=1
+```
+※ LEGACY 専用。C7_SAFE / C7_ULTRA_BENCH ではこのプリセットを使用しないこと。
 ```
 - flatten は LEGACY 専用。C7_SAFE / C7_ULTRA_BENCH ではコード側で強制 OFF になる前提。
 

docs/analysis/MID_LARGE_CPU_HOTPATH_ANALYSIS.md

@@ -38,6 +38,15 @@
 - perf stat（同条件 1M/400）: cycles=225,766,496、instructions=528,335,613、task-clock=57.88ms、ops/s≈25.7M。
 - 所感: fast-path整理だけでは効果薄く、むしろ低下。pool 内の memset/desc まわりやリング補充順序をより大胆に削らないと改善しない。次のステップとして追加の枝削減・キャッシュ導入を検討。
 
+## Phase MD1（mid_desc_lookup TLS キャッシュ）
+- 目的: C6-heavy/mid で目立つ mid_desc_lookup を TLS 1 エントリでキャッシュし、サイズが同じリクエストが続くケースで self% を削る。
+- ENV ゲート: `HAKMEM_MID_DESC_CACHE_ENABLED=1`（デフォルト OFF）。miss 時は従来の `mid_desc_lookup` にフォールバック。
+- baseline self%: mid_desc_lookup≈3.8%（Phase54 perf, C7_SAFE）。
+- A/B（C6_HEAVY_LEGACY_POOLV1, 1M/400, flatten OFF, zero=full）:
+  - cache OFF: 28.90M ops/s
+  - cache ON : 29.83M ops/s（**+3.2%**）segv/assert なし。
+- Mixed 16–1024B (C7_SAFE front v3/LUT/fast classify ON): cache OFF 44.83M → ON 44.94M（+0.3%）。perf (cycles:u, release) では mid_desc_lookup は上位に出ず、self% 影響はごく小さい。
+
 ## Phase57 回帰トリアージ（pool v2 をゲート化）
 - 変更: `HAKMEM_POOL_V2_ENABLED` を追加し、v1/v2 の pool 実装を env で切替。細分スイッチとして `HAKMEM_POOL_V2_BLOCK_TO_USER` / `HAKMEM_POOL_V2_TLS_FAST_PATH` を用意（デフォルト ON, v2 時のみ有効）。
 - ベンチ（C6-heavy, 1M/400, Release）:

docs/analysis/TINY_CPU_HOTPATH_USERLAND_ANALYSIS.md

@@ -78,6 +78,22 @@ Throughput: **12.39M ops/s**（DEBUG/-O0 相当）
 - そのほか: free/malloc/main が約 30% 強、header write 系は今回のデバッグログに埋もれて確認できず。
 
 所感:
+
+## Phase HF1（DEBUG, front v3+LUT+fast classify+mid_desc_cache ON）
+- ビルド: `CFLAGS='-O0 -g' USE_LTO=0 OPT_LEVEL=0 NATIVE=0`
+- ENV: `HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE`, `HAKMEM_MID_DESC_CACHE_ENABLED=1`
+- コマンド: `perf record -F 5000 --call-graph dwarf -e cycles:u -o perf.data.tiny_mixed_hf1 ./bench_random_mixed_hakmem 1000000 400 1`
+- self% 上位（perf_tiny_mixed_hf1.txt 抜粋）:
+  - tiny_alloc_gate_fast 16.85%
+  - free 13.63% / malloc 13.34% / main 9.02%（ベンチ枠）
+  - __memset_avx2_unaligned_erms 5.65%（初期化）
+  - hak_super_registry_init 5.57%（初期化）
+  - so_alloc_fast 2.41%, unified_cache_push 2.23%
+  - tiny_front_v3_enabled 2.23%, tiny_front_v3_lut_lookup 2.21%
+  - smallobject_hotbox_v3_can_own_c7 1.94%
+  - tiny_region_id_write_header 1.82%
+  - ss_map_lookup 1.61%, mid_desc_lookup_cached 0.98%, classify_ptr 0.65%
+所感: TF3 + mid_desc_cache 適用後、ss_map_lookup/self% は 1.6% まで沈み、tiny_region_id_write_header が引き続き ~1.8% で上位。次の削り候補は header 書き込み回数削減 or front前段の小枝刈り。
 - front v3 + LUT ON でも free 側の `ss_map_lookup` / `hak_super_lookup` が ~11% 程度残っており、ここを FAST classify で直叩きする余地が大きい。
 - `classify_ptr` は 1% 未満だが、`ss_map_lookup` とセットで落とせれば +5〜10% の目標に寄せられる見込み。