v0.7.5 — log cleanup for WiFi-native locks

v0.7.4 is confirmed working on hubless WiFi-native locks — two PGK728WRHK (Lockly Visage) on firmware 1.14.31 and 3.00.24, both locking and unlocking over the broker, reported within hours of the release by the user who diagnosed the frame.

This release fixes the logging, which was still describing those locks as unsupported and every one of their commands as a failure.

Fixes

• An empty hubid is no longer a warning. It means the lock is WiFi-native and reaches the cloud on its own. mc and hc still warn, because those genuinely break commands.
• "WiFi-native locks are not yet supported; see issue #2" is gone. It was logged at ERROR once per command, on locks that were working. It is now a debug line saying the command is going over MQTT instead.
• "failed — see the senddata warning above" no longer precedes a successful unlock. It was logged before the MQTT fallback had even been attempted, so on a hubless account it sat above every command that then succeeded. The attempt is now an info line, and the warning appears only if both transports fail.
• cod=930 reads as expected rather than fatal on a lock with no hub.

Docs

The README no longer says locks without a hub are unsupported. It records that hubless WiFi-native locks work from 0.7.4, on which hardware that was verified, and what is still missing on them: senddata's state and access-log queries are refused for the same reason commands were, and QueryPwd147 (0x93) answers 0xFA, so the host credential comes from the cloud's copy rather than from the lock. Neither blocks locking or unlocking.

docs/api.md records the 0x52 layout as confirmed on hardware rather than derived from source alone.

Unchanged

No frame or transport changes. If 0.7.4 works for you, 0.7.5 behaves identically and says less about it.