Fix 1KB-8KB allocation gap: Close Tiny/Mid boundary

Problem: 1024B allocations fell through to mmap (1000x slowdown)
- TINY_MAX_SIZE: 1023B (C7 usable size with 1-byte header)
- MID_MIN_SIZE:  8KB (was too large)
- Gap: 1KB-8KB → no allocator handled → mmap fallback → syscall hell

Solution: Lower MID_MIN_SIZE to 1KB (ChatGPT recommendation)
- Tiny: 0-1023B (header-based, C7 usable=1023B)
- Mid:  1KB-32KB (closes gap, uses 8KB class for sub-8KB sizes)
- Pool: 8KB-52KB (parallel, Pool takes priority)

Results (bench_fixed_size 1024B, workset=128, 200K iterations):
- Before: 82K ops/s (mmap flood: 1000+ syscalls/iter)
- After:  489K ops/s (Mid allocator: ~30 mmap total)
- Improvement: 6.0x faster ✅
- No hang: Completes in 0.4s (was timing out) ✅

Syscall reduction (1000 iterations):
- mmap:    1029 → 30   (-97%) ✅
- munmap:  1003 → 3    (-99%) ✅
- mincore: 1000 → 1000 (unchanged, separate issue)

Related: Phase 13-A (TinyHeapV2), workset=128 debug investigation

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

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

core/hakmem_tiny.h

@@ -23,7 +23,9 @@ int hak_is_initializing(void);
 
 #define TINY_NUM_CLASSES 8
 #define TINY_SLAB_SIZE (64 * 1024)  // 64KB per slab
-#define TINY_MAX_SIZE 1024          // Tiny handles up to 1024B (C7 headerless)
+// Phase E1-CORRECT: All Tiny classes use a 1-byte header.
+// C7 stride=1024B → usable 1023B (1024-1). 1024B は Mid allocator に委譲する。
+#define TINY_MAX_SIZE 1023          // Tiny handles up to 1023B (C7 usable size)
 
 // ============================================================================
 // Size Classes