Authenticate with the binding refresh when a device reports its binding as unverified

[GnoX]

This PR lets a device whose binding is no longer verified authenticate again on its own, instead of failing every connection until someone opens the EcoFlow app. A device advertises whether it still holds a verified binding for the account, and that flag decides which of two authentication messages it will accept: the one that checks the binding, or the one that writes it back. We only ever sent the check, so a device that stopped reporting itself as verified could never recover locally.

Both messages carry the same secret we already compute, so the fix is to send the one the device is asking for.

Full list of changes:

• The authentication message is chosen from the advertised flag, exactly as the app chooses it: the check while the device reports a verified binding, the refresh while it does not. A device that does not advertise the capability at all keeps the previous behaviour.
• A device that answers the check by saying it needs binding first gets the refresh too, once, whatever it advertised. That reply is the other way this state shows up, and it is what several older reports of this failure carried before they were closed with the advice to remove and re-add the device in the app.
• Either reply is accepted as the authentication result, since the device answers whichever message it was sent and the success code is the same for both.
• The log line says which path was taken, because the two failure modes look identical from the outside and a report of "authentication failed" is otherwise unactionable.
• Nothing is unbound and no network settings are touched, and the retry happens at most once per connection so a device that keeps refusing still fails rather than looping.

A device holding a binding for a different account is unaffected: asked to refresh with a secret that is not its own, it refuses and keeps the binding it has. So this cannot move a device between accounts, and it equally cannot repair that situation, which still needs the device to be removed and re-added.

Verified on a Delta 3 Plus. While the device advertised a verified binding it authenticated through the check as before, and a refresh was refused with an error code and the link dropped, which is what makes the flag worth reading rather than always writing. After clearing the binding the device advertised itself as unverified, and this branch authenticated it immediately over Bluetooth with no app and no internet involved. The needs-binding reply could not be reproduced on that device on demand, so that path is covered by unit-level checks rather than hardware; reporters whose devices fall into this state every few days are the ones who can confirm the recurring case, which no local test can reproduce.

Resolves #471