Fix double mutex unlock in concurrent contract save queue

[Copilot]

Addresses feedback from PR #2131 regarding a mutex double-unlock bug in saveData().

Issue

When the save queue is full, break only exits the select statement, not the for loop, causing execution to fall through to a second unlock:

saveQueueMutex.Lock()
select {
case saveQueue <- contractHash:
    // Successfully queued
default:
    saveQueueMutex.Unlock()  // First unlock
    break                     // Only exits select, not for loop!
}
saveQueueMutex.Unlock()      // Second unlock → panic

Fix

Replace break with continue to skip the second unlock when queue is full:

default:
    saveQueueMutex.Unlock()
    continue  // Skip to next loop iteration

---

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

[Copilot]

Pull request overview

Fixes a concurrency bug in saveData() where the “save queue full” path could fall through and unlock the same mutex twice.

Changes:

• Replace break with continue in the queue-full default branch to skip the outer unlock.
• Explicitly unlock saveQueueMutex before continuing to the next loop iteration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

In the default branch, log.Printf runs while saveQueueMutex is held. Logging can block (I/O) and prolong mutex hold time, which may increase contention and delay the worker’s pendingSaves cleanup under load. Consider unlocking before logging (capture contractHash first) and keeping the locked section minimal; optionally rate-limit this message to avoid log spam when the queue is full.