WHB04 reconnects and drops paired STOP/RESET input on unknown button codes

[righteousgambit]

Controller version

develop at 2ea66c10e96d88013a04441134d3d4f8e8c88510. This is controller-side pendant handling; firmware is not involved in the failure.

Reproduction

Feed the WHB04 parser one valid eight-byte packet containing a valid safety/action button in either button slot and an unknown nonzero value in the other slot:

packet = struct.pack(
    "BBBBBBbB",
    0x04,
    0,
    Button.STOP.value,  # RESET reproduces it too
    0xFF,               # unknown/transient value
    StepSize.LEAD.value,
    Axis.OFF.value,
    0,
    0,
)
daemon._process_input_packet(packet)

The same result occurs with the two button slots reversed.

Expected

Ignore the unknown button value, preserve the valid button from the same packet, and dispatch its callback without cycling the pendant connection.

Actual

Both nonzero bytes are converted directly to Button enum members. Button(0xFF) raises ValueError before callbacks are dispatched, so the valid STOP/RESET value in the same packet is dropped. In the live device loop that exception reaches the generic retry handler, closes the current HID guard, reports a disconnect, and reconnects.

The parser already tolerates transient unknown rotary-axis and step-selector values, but not unknown button values: button parsing, device-loop propagation, retry/reconnect handler.

Impact

One malformed, noisy, or transient button byte can produce a visible pendant disconnect/reconnect and can discard a valid STOP or RESET indication paired in that report. This report demonstrates the controller failure deterministically; it does not claim a particular hardware frequency.

Regression proof

A four-case test matrix covers STOP and RESET with the unknown value in each slot. Against the pinned base it fails all four cases with ValueError: 255 is not a valid Button.