release: 0.17.1

[cuican-reolink]

A device refusing a download no longer reads as the stream simply ending.

The receive loop treated an empty frame as end-of-stream, and a refusal is an empty frame carrying a non-200 code — so the refusal was swallowed and a time-range download reported "no recording in that window" instead. On a model that does not implement the cut command at all, that diagnosis is wrong and sends you looking in the wrong place.

Response codes are now read the way the reference implementation reads them: 200 carries data, 300 ends a download by name, 331 ends a cut, anything else is the device saying no.

This came out of a control experiment worth recording: an NVR answered 400 to the cut command, but so did a camera that demonstrably does support it, when asked for a window holding no recording. A 400 therefore cannot tell "unsupported" from "nothing there" — v0.17.0's note implied it could. Since the CLI searches before it cuts, a 400 arriving after recordings were found is now reported for what it most likely is.

Regression test drives the whole path over a scripted transport (login → search → a 400 frame); with the fix reverted it fails on exactly the old wrong message.

Artifacts built external (LAN-only, no P2P) for all 8 platforms; the P2P fingerprint gate reports clean on every one, and checksums/v0.17.1.sha256 comes from the build machine.

[reolink-net]

Release sync verified: 8 external artifacts, P2P gate clean on all, checksums from the build machine. Regression test proven to fail without the fix.