Fix blockQueueSize data race by moving to atomic section

[Copilot]

Addresses data race where blockQueueSize was documented as mutex-protected but accessed atomically, creating potential for incorrect assumptions about thread safety.

Changes

• Moved blockQueueSize and blockQueueLen from mutex-protected section to atomic variables section in Client struct
• Ensures proper 64-bit alignment required for atomic operations
• Documents actual access pattern (all existing accesses were already atomic)

type Client struct {
    // variables used in atomic operations (declared first for alignment)
    msgNum              uint32
    sendworkers         int32
    transmittedBlocks   int32
    skippedBlocks       int32
+   blockQueueLen       int32  // atomic access
    WriteData           int64
    WriteDataCompressed int64
+   blockQueueSize      int64  // atomic access
    
    // mutex protected
    dispatchMutex  sync.Mutex
-   blockQueueSize int64  // incorrect - actually atomic
-   blockQueueLen  int32  // incorrect - actually atomic
    blockQueueMap  map[Byte128]*blockQueueEntry
    blockQueueList []*blockQueueEntry

All access points (queue size checks, compression adjustments, stats) already use atomic operations correctly.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.