fix: correct lock ordering in processMeshRequest to prevent deadlock

The previous lock ordering in processMeshRequest was:
  epochLock -> sizeLock -> arenaLock

This conflicted with meshAllSizeClassesLocked (called via mallctl
mesh.compact with AllLocksGuard) which uses:
  sizeLocks[0..N-1] -> arenaLock -> epochLock

This inconsistent ordering could cause deadlock:
- Thread A (mallctl): holds miniheapLocks, waits for epochLock
- Thread B (processMeshRequest): holds epochLock, waits for miniheapLock

Fix by reordering processMeshRequest to match the established order:
  sizeLock -> arenaLock -> epochLock

Also moves drainPendingPartialLocked inside the epoch-locked section
to match the pattern in meshAllSizeClassesLocked.

Author: bpowers

src/global_heap_impl.h

@@ -331,10 +331,9 @@ void GlobalHeap<PageSize>::processMeshRequest(size_t sizeClass) {
   bool aboveThreshold = false;
 
   {
-    lock_guard<EpochLock> epochLock(_meshEpoch);
+    // Lock ordering: size-class lock -> arena lock -> epoch lock
+    // This matches meshAllSizeClassesLocked (called via AllLocksGuard in mallctl)
     lock_guard<mutex> sizeLock(_miniheapLocks[sizeClass]);
-    drainPendingPartialLocked(sizeClass);
-
     lock_guard<mutex> arenaLock(_arenaLock);
 
     // if we have freed but not reset meshed mappings, this will reset
@@ -345,6 +344,10 @@ void GlobalHeap<PageSize>::processMeshRequest(size_t sizeClass) {
     if (Super::aboveMeshThreshold()) {
       aboveThreshold = true;
     } else {
+      // Acquire epoch lock last to match lock ordering in meshAllSizeClassesLocked
+      lock_guard<EpochLock> epochLock(_meshEpoch);
+
+      drainPendingPartialLocked(sizeClass);
       flushBinLocked(sizeClass);
       meshCount = meshSizeClassLocked(sizeClass, scratch.mergeSets, scratch.left, scratch.right);
       madvise(&scratch.left, sizeof(scratch.left), MADV_DONTNEED);