v0.7.10 — ask the lock what the door is doing

Adds lockly.refresh_door_state, contributed by @Dei381rcr.

Why it exists

The door sensor updates when the lock is commanded and, on WiFi-native locks, when the lock pushes a state callback. Neither covers a door that opens and closes without the lock being touched — and on a Lockly Visage no magnet state appears to be pushed at all, so a door could open with Home Assistant none the wiser. Reported with reproductions on #10.

The service asks the lock directly and publishes what it answers. The reading lands on the door entity and on a lockly_door_state_refreshed event carrying lock_id and door_open, so an automation can act on the answer it asked for. A door_open of null means the lock did not answer — which is deliberately not the same as a closed door.

It wakes the lock. This sends a real Bluetooth status frame, so the lock may chirp. Call it when you need a current reading, not on a timer. It is MQTT-only: a hub-relayed lock cannot answer it.

Also in this release

The repository now runs CI on every push and pull request — ruff, plus both test suites. The tests need no network, broker or hardware, so there was never a good reason they only ran on one machine.

The lint rules are deliberately narrow: pycodestyle and pyflakes, nothing about taste. It exists for a specific reason. Three pull requests in a week carried trailing whitespace on a blank line, one of them a PR whose only purpose was removing trailing whitespace, and it survived three attempts — because github.com renders a whitespace-only line identically to an empty one and no reviewer can see the difference. A machine can.

Unchanged

No frame, transport or state-parsing changes.