Add support for F_C__Y___W.A__QEUK washing machine

[martijndhondt]

Summary

• Adds device support for the LG F_C__Y___W.A__QEUK front-loading washer (A-generation UK), decoding the 62-byte 0x20 0xEC status packet, the compact 32-byte 0x20 0xEB variant, and the 3-byte 0x20 0xD8 door-state packet.
• Exposes power, status, course, temp, spin, remote_start, door_lock, child_lock, steam, wrinkle_care, active, pre_state, tub_clean, initial/remaining/delay time, and error/error_message. All byte offsets were confirmed against live packet captures cross-checked against known machine settings and the Home Assistant UI, including a real dE2 (door lock error) capture.
• Fixes send_packet in cloud/thinq2/device.ts to emit uppercase hex, which this device's firmware requires.

This was developed with the assistance of Claude (Anthropic) — packet captures were analysed and offsets cross-verified against known settings and HA UI state interactively.

Test plan

• tests/cloud/devices/F_C__Y___W.A__QEUK.test.ts — 38/38 passing, covering all decoded fields, the 0xD8 door-lock precedence rules, 0xE2 packet ignoring, and the error/error_message decoding
• Full test suite run on this branch (excluding two pre-existing, unrelated Windows-only flaky tests already present on master)

[anszom]

excluding two pre-existing, unrelated Windows-only flaky tests already present on master

I'm not aware of those, but I haven't tried running on Windows. What are you referring to?

[martijndhondt]

Sorry, should've been more specific. Both are on master/upstream too (I checked with a clean upstream/master checkout before making any changes), just Windows-specific:

tests/bridge/util.test.ts → "subprocess rejects signals and spawn failures"
The test spawns a child Node process that calls process.kill(process.pid, 'SIGTERM') on itself, expecting bridge/util.ts (lines 66-78) to report terminated by SIGTERM. Windows has no real POSIX signal delivery — Node's docs note process.kill() on Windows unconditionally terminates the process rather than delivering an actual signal, so child_process's 'close' event reports signal: null, code: 1 instead of signal: 'SIGTERM'. That routes into the code !== 0 branch, producing "exited with code 1" instead of "terminated by SIGTERM". Documented Node/Windows limitation, not a bug in the util code.

tests/management/device-monitor.test.ts → "device monitor detaches device and manager listeners after a real WebSocket close"
Fails at line 39 — assert.equal(device.listenerCount('data'), 0) gets 1 instead. The test does ws.close(); await once(ws, 'close') then immediately asserts the server has already detached the device's listeners. On Windows the server-side close handling appears to lag behind the client seeing its own 'close' event — a client/server socket-close ordering race that Windows' networking stack surfaces more readily than Linux's. Since the assertion throws, server.close() on line 45 never runs, leaving the server listening — which is also why the suite takes noticeably longer to settle afterward.

Neither touches the washer device code, and both reproduce identically on a bare upstream/master checkout, so they're pre-existing and out of scope for this PR.