Remove Windows x86 mutex workaround when Swift preserves stdcall

[compnerd]

Windows x86 DSX builds successfully with Swift 6.4 DEVELOPMENT-SNAPSHOT-2026-08-28-a, but starting dsx platform --server --listen 127.0.0.1:0 exits with 0xc0000005 before listening. Version and help succeed.

CI evidence: https://github.com/compnerd/DSX/actions/runs/34539491428/job/103079996412

A reduced local Swift reproduction using Synchronization.Mutex.withLock, and a second using direct WinSDK calls, emits ordinary C calls to AcquireSRWLockExclusive and ReleaseSRWLockExclusive even though their LLVM declarations use x86_stdcallcc. The mismatched stack-cleanup convention corrupts the x86 stack. The existing WSAStartup C shim does not cover the SRW calls inside Synchronization.

Track a targeted Windows x86 mutex implementation whose SRW calls cross a C shim (Clang owns the stdcall boundary). Other platforms should continue using Synchronization.Mutex. This is a temporary workaround, not a general repair of Swift's WinSDK call lowering.

Removal criteria:

• The supported Swift toolchain emits matching calling conventions for both direct WinSDK and Synchronization SRW calls on i686 Windows.
• Windows x86 mutex contention and lifetime tests pass.
• The packaged Windows x86 DSX platform startup/qHostInfo smoke check passes using Synchronization.Mutex.
• Remove the targeted mutex and its C shims together after validation.