Phase 6-2.6: Fix slab_data_start() consistency in refill/validation paths

Problem:
- Phase 6-2.5 changed SUPERSLAB_SLAB0_DATA_OFFSET from 1024 → 2048
- Fixed sizeof(SuperSlab) mismatch (1088 bytes)
- But 3 locations still used old slab_data_start() + manual offset

This caused:
- Address mismatch between allocation carving and validation
- Freelist corruption false positives
- 53-byte misalignment errors resolved, but new errors appeared

Changes:
1. core/tiny_tls_guard.h:34
   - Validation: slab_data_start() → tiny_slab_base_for()
   - Ensures validation uses same base address as allocation

2. core/hakmem_tiny_refill.inc.h:222
   - Allocation carving: Remove manual +2048 hack
   - Use canonical tiny_slab_base_for()

3. core/hakmem_tiny_refill.inc.h:275
   - Bump allocation: Remove duplicate slab_start calculation
   - Use existing base calculation with tiny_slab_base_for()

Result:
- Consistent use of tiny_slab_base_for() across all paths
- All code uses SUPERSLAB_SLAB0_DATA_OFFSET constant
- Remaining freelist corruption needs deeper investigation (not simple offset bug)

Related commits:
- d2f0d8458: Phase 6-2.5 (constants.h + 2048 offset)
- c9053a43a: Phase 6-2.3~6-2.4 (active counter + SEGV fixes)

🤖 Generated with Claude Code

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

core/hakmem_tiny.c

@@ -36,7 +36,7 @@ int g_debug_fast0 = 0;
 int g_debug_remote_guard = 0;
 int g_remote_force_notify = 0;
 // Tiny free safety (debug)
-int g_tiny_safe_free = 0;         // env: HAKMEM_SAFE_FREE=1
+int g_tiny_safe_free = 1;         // ULTRATHINK FIX: Enable by default to catch double-frees. env: HAKMEM_SAFE_FREE=1
 int g_tiny_safe_free_strict = 0;  // env: HAKMEM_SAFE_FREE_STRICT=1
 int g_tiny_force_remote = 0;      // env: HAKMEM_TINY_FORCE_REMOTE=1