Restore component state from mqtt state topic after reboot

**Describe the problem you have/What new integration you would like**

Restoring data from flash puts our device in risk with flash writes. If we want to reduce this risk, we must sacrifice some recent data. Restoring data from RTC is limited and not surviving a power failure.

What if the state of selected components could be restored from the mqtt broker?

**Please describe your use case for this integration and alternatives you've tried:**

This would be usefull for storing component data where is important to recover the latest state, like the position of an actuator, a counter, an integration, an average, ....

I would have tried with the mqtt_subscribe component, but I discarded the idea rapidly.

**Additional context**

This would require for selected components to:
- have an mqtt_restore attribute?
- delay initialisation until the device is connected to the mqtt broker / timeout management.
- subscribe to the state topic / error management.
- wait for the retained state to arrive / timeout management.
- discard the value if it is too old?
- unsubscribe from the state topic.
- when publishing component state, enforce the retained flag.

Of course, also we need to setup an mqtt broker that supports retained messages and that is not using a scard or usb stick as permanent storage.

PRO: a great improvement for the safety and use cases of our devices.
CON: when the device boots it will depend on mqtt broker survival and avaliability.

Start by defining how selected component state should be represented and restored through the MQTT broker. Resolve retained-topic subscription, initialization delay, timeout, stale-value handling, error handling, and unsubscribe behavior before implementation. Done should include a clear component-facing design and reliable reboot recovery without requiring flash writes.

Written by the indexing model from the issue text.