Comply with POSIX thread ownership

[osm]

Problem

Previously, the broadcast code performed the following:

• A thread would Sys_MutexTryLock() a mutex (servers_update_lock or broadcast_lock).
• It would then spawn a worker thread to handle the long running task.
• The worker thread was responsible for unlocking the mutex.

This violates POSIX threading rules, which state that a mutex must only be unlocked by the thread that locked it. Unlocking from another thread is undefined behavior and can lead to crashes or data races, especially on strict POSIX-compliant systems.

Fix

• Introduced update_in_progress and broadcast_in_progress flags to track whether an operation is already running.
• These flags are protected by their respective mutexes and checked/set within the same thread that acquires the mutex.
• The worker threads now independently acquire the mutex before modifying shared state or releasing the lock.
• Added a Sys_MutexLock() function to complement Sys_MutexUnlock(), enabling proper lock/unlock pairs within the same thread.

Recommendation

I recommend you to copy the following osm@570645c from my fork and apply it in your upstream repo. It resolves the mutex misuse while keeping the surrounding logic unchanged.

[ripednail]

Would you be willing to look at my git hub with multi threading and convert to the new mvdsv ? https://github.com/ripednail/multi-threaded-mvdsv

There's arm simd
Server thread Cvars
Ktx rules improvements
Main loop idle improvements