Fix GetTask response schema length mismatch

[gruijter]

Problem

The current GetTask responseType schema has an expected size of 17 bytes (start: 4, duration: 4, 7 bools: 7, unknown: 2). However, mowers send 19 bytes of data for this command. Under normal operation, this triggers a decoding failure:
ValueError: Data length mismatch. Read 17 bytes of 19

(Note: The existing unit test previously did not catch this because the mock hex string used was truncated to 17 bytes, matching the length mismatch but silently parsing it due to array slicing).

Solution

This PR changes the unknown field at the end of the GetTask responseType schema from uint16 (2 bytes) to uint32 (4 bytes). This brings the expected size to 19 bytes, matching the actual data structure returned by the mowers.

Verification

• Updated test_decode_get_task_response in tests/test_response.py with a complete, non-truncated 19-byte hex payload.
• Added assertions to check that the trailing unknown field decodes to 0 and that the overall test suite passes successfully.

[gruijter]

Note: this may overlap with #148 — happy to close/rebase once that lands, whichever the maintainer prefers.

[alistair23]

The current GetTask responseType schema has an expected size of 17 bytes

What is the source for this? We have an existing unit test that would be based on real data

[gruijter]

It's a raw capture from my own device, a Gardena Sileno Minimo 250, via BLE sniffing during normal operation:
Final response: 02fd2400b63b6047014101af52120500001300f0d200001815000000010000010000000000003903

That decodes to 19 bytes of payload after the header, consistently, across many calls on this specific model.

I don't have a Husqvarna Automower to verify whether it genuinely sends 17 bytes (matching the existing test) or whether that test fixture was itself built on an assumption. So this may well be a Gardena-specific variant rather than a universal bug — in which case a blanket schema change to 19 bytes isn't the right fix, since it could break automower parsing.

Given that, and given #148 appears to add support for variable-length trailing fields, that's probably the better long-term solution here rather than my fixed 19-byte schema change. I will close this PR n favor of #148.