v0.4.1 — Japanese view titles no longer get dropped

Install this if your windows show Japanese view titles or locations. They
were being silently discarded whenever the text happened to straddle a
Bluetooth packet boundary.

Fixed

A notification boundary falls wherever the window's MTU puts it, with no regard
for character boundaries, so a multi-byte character arrives in two pieces. The
JSON reader decoded each packet on its own, which raises on both halves,
and the client discards a payload it cannot decode. The update was lost, not
delayed.

Atmoph is a Japanese company and their view titles and locations are Japanese
text, so for the notification carrying them this is the ordinary case rather
than an edge one. Reproduced with a title split one byte into a three-byte
character.

Decoding is now incremental: the decoder holds a partial character until the
rest of it arrives. Genuinely malformed bytes still raise, and now also clear
the buffer, because a stream that has lost sync makes everything already in it
suspect.

Documentation

Records that this integration does not request an MTU where the app asks
for 128. A bleak client cannot portably, because BlueZ and CoreBluetooth
negotiate on the host's behalf — which is exactly why nothing may assume a
payload size, and why the incremental decode above is load-bearing rather than
defensive.

Testing

80 tests: 28 protocol, 52 Home Assistant layer. Two new protocol tests cover a
character split across packets and recovery after undecodable bytes.

An automated review of the test suite found that deleting the notification
dispatcher entirely leaves every test passing, so the push path is materially
untested even though this integration declares local_push. That is being
addressed next and is the reason this release is not described as verified.