Fixes #1743

Problem

The IPC lock tests are increasingly flaky on Windows CI. The root cause is a protocol-level bug where the server accumulates orphaned waiters and contexts when clients time out waiting for lock acquisition.

The race condition

When two threads compete for an exclusive lock via IPC:

1. Thread A acquires the lock, Thread B is added as a waiter on the server
2. B's client-side CompletableFuture.get(time, unit) times out → doLockExclusively() returns false
3. A unlocks → server promotes B's waiter → server sends RESPONSE_ACQUIRE to client
4. But B already moved on — the response hits a stale/missing entry in the responses map
5. B's context is never closed (no REQUEST_CLOSE sent) → server thinks B holds the lock → corrupted state for subsequent tests

On Windows, higher IPC latency widens the race window significantly.

Fix

Three targeted changes:

1. IpcNamedLock.doLockShared() / doLockExclusively(): When client.lock() throws TimeoutException, send client.unlock(contextId) to clean up the server-side context and waiter before returning false. Previously the context was leaked.

2. IpcClient.send(): On TimeoutException, remove the CompletableFuture from the responses map so late server responses don't hit stale entries.

3. IpcClient.receive(): When the response map lookup returns null (response arrived for a timed-out request), continue gracefully instead of throwing IllegalStateException("Protocol error") and killing the connection.

Re-enabled all three IPC test classes on Windows (@DisabledOnOs(OS.WINDOWS) removed from IpcAdapterIT, IpcAdapterNoForkIT, IpcNamedLockFactoryIT).

All 32 tests pass consistently.