Hold sensor values per sensor instead of per connection

[michaelarnauts]

The workaround for the invalid sensor values that the bridge sends when we subscribe to a sensor used a single timer, started when the connection was set up. _sensor_callback dropped everything while that timer was pending and _unhold_sensors flushed the last cached value per sensor.

That only covers sensors that are already subscribed when the timer starts. Home Assistant registers its sensors from async_added_to_hass(), so register_sensor() runs after connect() returned, and each call sends a fresh cmd_rpdo_request that the bridge answers with a bogus 0 before the real value. When entity setup finishes within the hold the garbage is swallowed (the usual case), but on a cold boot setup takes longer than the hold, so the 0 reached the callback and polluted statistics.

Every sensor now gets its own hold, started when we subscribe to it:

• _hold_sensor() / _unhold_sensor() replace the global handle with _sensor_holds, keyed by PDID.
• _reconnect_loop() holds all known sensors before re-issuing their RPDO requests, as before.
• register_sensor() holds the sensor before subscribing — this is the case that was unprotected.
• deregister_sensor() cancels a pending hold so a removed sensor cannot emit a late value.
• The default sensor_delay goes from 2 to 5 seconds, to give slower bridges more room.

sensor_delay=0 still disables the mechanism entirely.

test_sensor_hold_when_registered_after_connect covers the regression: it connects, waits past the connect-time hold, registers a sensor and feeds it 0 followed by 69. Without the hold in register_sensor() it fails on the 0 leaking through.

Fixes #67

🤖 Generated with Claude Code