Synchronize updater status access

[dajiaohuang]

The update worker and front ends access the status queue and ZSync client concurrently. Protect the message queue, publish the client with atomic shared-pointer operations, and synchronize state reads and error-state writes. Readers outside the updater mutex retain client snapshots for their use.

This revision removes two unnecessary snapshots: progress already holds the same mutex as every client write; the worker run phase follows initialization, after which checkForChanges sees a non-INITIALIZED state under that mutex and cannot replace the pointer. Necessary synchronization remains unchanged.

Validation on Linux x86_64 (GCC 13 / CMake 3.28):

• Native RelWithDebInfo C++17 core/CLI build passed, including shared/static libappimageupdate, appimageupdatetool, validate and bundled zsync tools. Used the upstream-supported LIBAPPIMAGE_SHARED_ONLY build, Qt disabled, and task-local dependencies: pinned zsync2, libappimage, CPR 1.8.3, args 6.4.7, curl 7.80.0 and zlib-ng 2.0.5. No production build files changed.
• 32 isolated native public-API polling processes passed using synthetic ELF/AppImage fixtures: invalid update information and a ZSync client connection failure, exercising status/state/progress/path/size queries while the worker runs. The original PR head also passed the same two cases. These check those paths, not race freedom or successful updates.
• ThreadSanitizer compiled the updater and consumer, but failed at runtime startup with FATAL: ThreadSanitizer: unexpected memory mapping; no TSan pass is claimed. Dependencies were linked from the normal build, not fully instrumented.

All configure/build/runtime processes used isolated network namespaces. No real user AppImage, external update feed, signature keys or system package installation was used. The fixture keeps its updater alive until process exit; Qt behavior, successful updates and cancellation/destruction are not validated here (the separate cancellation report #266 remains unresolved).

Hosted CI has not been rerun manually or verified for this revision. The previous head failed before source compilation when its Docker dependency step received Debian package HTTP 404 responses; that old result is not a candidate-build result.