Task: Implement Hotfix: default wire codec flip to msgpack breaks ores.qt.headless.tests

Asked explicitly whether CI had been checked "across all operative systems" – it had not; only Linux logs had been inspected up to that point. Pulled the latest Continuous MacOS and Continuous Windows run logs directly via gh run view --log, and found a second, unrelated failure: both fail to even compile ores.service/src/service/systemd_notify.cpp. macOS: error: 'sockaddr_un' does not refer to a value / use of undeclared identifier 'sun_path'. Windows: fatal error: 'sys/socket.h' file not found. Same file, same root cause on both: the file unconditionally #include=s =<sys/socket.h>=/=<sys/un.h> and uses sockaddr_un=/=AF_UNIX – POSIX/Linux-only APIs implementing the sd_notify(3) wire protocol, added by the systemd sd_notify-readiness work (merged as part of PR #1793/#1802) with no platform guard, even though its own header doc already says the function is "safe to call unconditionally" (true only if it compiles everywhere).

Confirmed no other file in the tree has the same unguarded-include pattern (grep -rl "sys/socket.h\|sys/un.h" projects/ – only this one file).

Fix: wrapped the whole Linux implementation in #if defined(__linux__) ... #else ... #endif, with a no-op body on the #else branch (macOS/Windows have no systemd to notify; a no-op is exactly the documented contract already, just now actually true cross-platform). Linux behaviour is byte-for-byte unchanged – same code, just now conditionally compiled. Verified the Linux build still compiles clean; macOS/Windows compilation cannot be verified locally (no cross-toolchain in this environment) and will be confirmed by CI on the PR.

User pushed back on the raw socket()=/=sendto()=/=sockaddr_un POSIX code as a hack, given the codebase already depends on Boost.Asio everywhere else (ores.nats etc.) and Asio wraps AF_UNIX datagram sockets directly. Rewrote using boost::asio::local::datagram_protocol::socket=/=endpoint, guarded by #if defined(BOOST_ASIO_HAS_LOCAL_SOCKETS) (Asio's own macro for "local sockets are available here", true on POSIX, false on Windows) rather than __linux__ directly – same practical effect (still a no-op on Windows; macOS could theoretically compile the real path too, though $NOTIFY_SOCKET is never set there in practice since macOS has no systemd) but ties the guard to what the code actually needs (Asio local-socket support) rather than a platform name. Removed all manual sockaddr_un=/=offsetof=/=memcpy packing – boost::asio::local::datagram_protocol::endpoint(path) builds the address, and socket::send_to() replaces ::socket()=/::sendto()=/ ::close(). The abstract-socket (leading @=/NUL byte) handling and the exact wire message (=READY=1) are preserved exactly. try/catch (...) replaces manual return-on-error checks, keeping the function's noexcept contract (Asio throws boost::system::system_error on failure; caught and swallowed, consistent with the original's best-effort semantics).

Verified: full local build clean (linux-clang-debug-make), full ctest 74/74 passed (re-run after this change, not just the earlier targeted ores.service.lib build). No unit tests exist for notify_systemd_ready() itself (before or after) – it is a fire-and-forget, environment-gated call with no meaningful behaviour to assert against outside a real systemd socket; not adding one now, consistent with the function's existing untested status.

Local Linux verification alone doesn't prove the macOS/Windows compile fix actually works – no cross-toolchain available in this environment. Both Continuous MacOS and Continuous Windows workflows support workflow_dispatch, so triggered both directly against this branch (gh workflow run ... --ref feature/implement-fix-wire-codec-default-breaks-headless-instrument-parse-tests) rather than waiting for the next main-scheduled run or merging blind.

Found a third real, distinct issue this way: windows-clang-debug-ninja failed with -Werror=deprecated-declarations on std::getenv (Windows/MSVC STL flags it in favour of _dupenv_s) – confirming along the way that BOOST_ASIO_HAS_LOCAL_SOCKETS genuinely is defined on this Windows toolchain (modern Windows supports AF_UNIX), so the real Asio-local-socket code path was compiling there too, just tripping on the unrelated getenv call. Fixed by using the project's existing ores::platform::environment::environment::get_value() helper (already used elsewhere in the codebase, e.g. ores.platform/src/environment/environment.cpp itself defines _CRT_SECURE_NO_WARNINGS internally to swallow this exact warning) instead of calling std::getenv directly – consistent with "no raw platform APIs where a project helper already exists," same principle as the boost::asio rewrite above. ores.platform.lib is already a transitive PUBLIC dependency of ores.service.lib (via ores.utility.lib), so no CMakeLists change needed.

Cancelled the in-flight Windows dispatch (doomed – all four Windows matrix variants would hit the identical getenv warning) rather than waiting for it to finish failing; macOS was left running since it was not failing on this issue (macOS's libc++ doesn't deprecate getenv), and gives an independent confirmation the Asio rewrite compiles there too. Re-verified locally on Linux (build + link clean) and pushed the fix; re-dispatching MacOS/Windows against the new commit to confirm before merging.