Ensure ChannelInfo mutex taken

[pljones]

Short description of changes

Addresses a missing Mutex issue.

CHANGELOG: SKIP

Context: Fixes an issue?

Reported server crash bug.

Does this change need documentation? What needs to be documented and how?

No

Status of this Pull Request

Needs fix verified by reporter.

What is missing until this pull request can be merged?

Review and testing.

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

[mcfnord]

🤖 AI: Confirmed against the reported crash. Under AddressSanitizer the reproducer — repeated short-lived connections to a server started with -R — reports a heap-use-after-free on unpatched main: the mix timer copies the channel name (CServer::AudioFrame) while the socket thread frees it through PutAudioData → FindChannel → InitChannel → ResetInfo(). On this branch the same run stayed clean across 128056 recorded connections over three reps, zero reports; the unpatched control reported at 69736.

One residual on the same field: bIsIdentified is now written under Mutex in ResetInfo() and SetChanInfo(), but the mixer reads it off that lock in PrepAndSendPacket (channel.cpp:719). ThreadSanitizer reports that read racing the ResetInfo() write at channel.cpp:364 — socket thread against the OnTimer mix thread — when a channel slot is recycled. Making it atomic, as bIsEnabled directly above it already is, closes that without putting Mutex on the per-frame path:

-    bool              bIsIdentified;
+    std::atomic<bool> bIsIdentified;

[softins]

Just double checking here. This was changed from a CChannelCoreInfo& to CChannelCoreInfo so that instead of returning a reference to the original, it returns a copy that was obtained under mutex protection?