v0.7.6 — external lock changes now reach Home Assistant on WiFi-native locks

Two fixes, both found by @Dei381rcr testing on hardware this project does not own. Also worth recording: the 0.7.4 frame fix is now confirmed on a third lock and a second model, a PGD728FG25 on issue #2.

External lock changes now arrive

Every version until now said real-time push was impossible without a Firebase token. That is still true of hub-attached locks. It was never true of WiFi-native ones — they push deviceStateCallback messages to our own client topic with no registration at all, and this integration was throwing every one of them away:

• it looked for the item list at the root of the message, where it actually sits under payload — the same place every other message this client handles keeps it
• it matched an uppercase LOCKED_STATUS key with the value "1"/"0", where a Visage sends a lowercase lock with the value locked/unlocked

Both readings came from the decompiled app, and neither had ever been checked against a live message. Both shapes are now accepted, so on a WiFi-native lock an unlock at the keypad or in the Lockly app reaches Home Assistant.

A state value in a form this does not recognise is now logged as a warning asking you to report it, rather than quietly being treated as False. Guessing wrong about a lock or a door is worse than saying so.

Door state is not covered by this. No magnet key has appeared in any captured callback from these locks, so the door sensor still only updates from a status query.

Status readings over MQTT are no longer discarded

_mqtt_nonce took the nonce and the lock type out of a status response and dropped the rest. On an account where senddata is refused, MQTT is the only transport, so the lock and door state parsed from every status query went in the bin. A door entity could sit stale, or stay unavailable for the life of the run, because nothing else ever proved its sensor was fitted.

It now publishes through the same path the senddata status query uses, extracted so the two cannot drift apart again, and that path fills in the sensor-proven flag the door entity's availability depends on. Verified by the reporter: a stale "open" corrected to closed, and an unavailable sensor came to life.

Unchanged

No frame or transport changes. Hub-attached locks behave exactly as in 0.7.5 — they still do not receive external state, for the Firebase reason, which has not changed.