feat: read alerts from the Tuya message centre, not only from device state

### What would you like to see? Read motion and sound alerts from the Tuya message centre instead of only from device state. ### Why do you want this — what problem does it solve for you? Alerts are currently read from the device's own data points, and on the SCD951 and SCD953 family that means DPS 212, which holds **one** alarm record and is not a queue. A second alert overwrites the first, and nothing guarantees a poll lands inside the window where a record is present. 2026.8.0 narrowed that window from 120 seconds to 30 and made pushes work where the LAN carries them, but the gap cannot be closed this way. @progrobin measured it on #61: a second noise 60 seconds after the first produced an app notification and no new DPS 212 value at all, so Home Assistant never fired. @leonardpitzu independently found on #51 that the app was notified while neither the LAN session nor the cloud poll saw anything, which points at the same place. The message centre is the source the app itself uses, and it is a list rather than a slot, so a burst of alerts cannot overwrite itself. ### Where the evidence comes from Extracted from the vendor app 1.9.1 (version code 42), read out of its dex string tables. All of these action names are present in the binary: | Action | Purpose | |--------|---------| | `thing.m.msg.list.by.json` | the message list | | `thing.m.msg.days.by.json` | which days have messages | | `thing.m.msg.remove` | delete a message | | `m.solution.msg.group.by.date` | messages grouped by date | | `m.solution.ipc.msg.sort.tag.get` | sort tags for camera messages | | `m.ipc.msg.algorithm.tag.get` | algorithm tags, the classification vocabulary | | `thing.m.playback.event.list` | the camera event timeline, an alternative source | Parameter names seen in the same binary: `devId`, `startTime`, `endTime`, `offset`, `limit`, `msgType`, `msgSrcId`, `type`. The same message centre also carries SleepIQ, classified through `com/thingclips/smart/ka/ipc/messagecenter/consts/SenseIQClassifyKeys`, so this work and #74 share a foundation. ### What it would take 1. Call `thing.m.msg.list.by.json` with a real session and work out the request shape from the parameter names above. The endpoint is known, so this is iteration rather than research. 2. Decide the polling story. A message list can be polled on a sane interval and deduplicated by message id, which is strictly better than sampling a single-slot data point. 3. Keep DPS 212 as the fast path where it works, since a LAN push on a 3.5 session arrives in about a second, well ahead of any polling. ### Anything else This would also make alerts work on families where the DPS route is unreliable or absent, and it is the same mechanism the Philips app uses, so it should be as complete as what a parent sees on their phone.