refactor: Guard SuperSlab expansion debug logs + Update CURRENT_TASK

## Changes

### 1. Debug Log Cleanup (Release Build Optimization)
**Files Modified:**
- `core/tiny_superslab_alloc.inc.h:183-234`
- `core/hakmem_tiny_superslab.c:567-618`

**Problem:**
- SuperSlab expansion logs flooded output (268+ lines per benchmark run)
- Massive I/O overhead masked true performance in benchmarks
- Production builds should not spam stderr

**Solution:**
- Guard all expansion logs with `#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)`
- Debug builds: Logs enabled by default
- Release builds: Logs disabled (clean output)
- Can re-enable with `-DHAKMEM_SUPERSLAB_VERBOSE` for debugging

**Guarded Messages:**
- "SuperSlab chunk exhausted for class X, expanding..."
- "Successfully expanded SuperSlabHead for class X"
- "CRITICAL: Failed to expand SuperSlabHead..." (OOM)
- "Expanded SuperSlabHead for class X: N chunks now"

**Impact:**
- Release builds: Clean benchmark output (no log spam)
- Debug builds: Full visibility into expansion behavior
- Performance: No I/O overhead in production benchmarks

### 2. CURRENT_TASK.md Update
**New Focus:** ACE Investigation for Mid-Large Performance Recovery

**Context:**
- ✅ 100% stability achieved (commit 616070cf7)
- ✅ Tiny Hot Path: **First time beating BOTH System and mimalloc** (+48.5% vs System)
- 🔴 Critical issue: Mid-Large MT collapsed (-88% vs System)
- Root cause: ACE disabled → all allocations go to mmap (slow)

**Next Task:**
Task Agent to investigate ACE mechanism (Ultrathink mode):
1. Why is ACE disabled?
2. How does ACE improve Mid-Large performance?
3. Can we re-enable ACE to recover +171% advantage?
4. Implementation plan and risk assessment

**Benchmark Results:**
Comprehensive results saved to: `benchmarks/results/comprehensive_20251108_214317/`

---

## Testing

Verified clean build output:
```bash
make clean && make HEADER_CLASSIDX=1 AGGRESSIVE_INLINE=1 PREWARM_TLS=1 larson_hakmem
./larson_hakmem 1 1 128 1024 1 12345 1
# No expansion log spam in release build
```

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

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

core/hakmem_tiny_superslab.c

@@ -564,11 +564,13 @@ int expand_superslab_head(SuperSlabHead* head) {
     // Allocate new chunk via existing superslab_allocate
     SuperSlab* new_chunk = superslab_allocate(head->class_idx);
     if (!new_chunk) {
+#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)
         extern __thread int g_hakmem_lock_depth;
         g_hakmem_lock_depth++;
         fprintf(stderr, "[HAKMEM] CRITICAL: Failed to allocate new chunk for class %d (system OOM)\n",
                 head->class_idx);
         g_hakmem_lock_depth--;
+#endif
         return -1;  // True OOM (system out of memory)
     }
 
@@ -607,11 +609,13 @@ int expand_superslab_head(SuperSlabHead* head) {
 
     pthread_mutex_unlock(&head->expansion_lock);
 
+#if !defined(NDEBUG) || defined(HAKMEM_SUPERSLAB_VERBOSE)
     extern __thread int g_hakmem_lock_depth;
     g_hakmem_lock_depth++;
     fprintf(stderr, "[HAKMEM] Expanded SuperSlabHead for class %d: %zu chunks now (bitmap=0x%08x)\n",
             head->class_idx, new_count, new_chunk->slab_bitmap);
     g_hakmem_lock_depth--;
+#endif
 
     return 0;
 }