Remove Windows x86 mutex workaround when Swift preserves stdcall

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.