[shsms]

A pool created without component IDs was keyed by an empty set, so it didn't share its reference store with the pool the power manager creates for the explicit IDs of the same components. This branch keys the stores by the resolved component IDs, and fixes the duplicate-pool warning, which had the same keying problem.

Changes

• ComponentPoolReferenceStore.resolve_component_ids() turns None or an empty set into all the IDs of the pool's type. _DataPipeline.new_*_pool() uses the result as the store key and passes it to the store, so the key and store.component_ids are the same set.
• The duplicate-pool warning is keyed by (store class, IDs, priority) instead of the text of the IDs. Equal sets can print in different orders, so the old key sometimes missed duplicates, and pools of different types without components warned about each other. The warning now prints the resolved IDs and the right new_*_pool() name.
• The tests run for all four pool types. Worth a look: the 6-component setup in test_pool_for_all_components_warns_like_explicit_ids. Its comment explains why a key made from the text of the IDs fails there.
• Side effect: report channel names come from the text of the store's ID set (ReportRequest.get_channel_name()). Before, two pools for the same batteries at the same priority could get names that didn't match, so the second pool's power_status channel never got a sender. Sharing one store fixes that.

[Marenz]

Looks good. I checked that the new tests fail on v1.x.x and pass here, and that sharing the store is safe: everything in it depends only on the component set.

A few small things:

1. The warnings still name the old parameters (ev_charger_ids=%s, pv_inverter_ids=%s, battery_ids=%s, steam_boiler_ids=%s in _data_pipeline.py); the keyword is component_ids now. Since this PR already edits those strings, maybe fix them too.
2. The release note describes the mechanism, but the visible bug was worse: with 11 or more batteries, two pools for the same components at the same priority got differently spelled channel names, and one of them never got power_status updates (I reproduced this on v1.x.x). Maybe say that in the note.
3. Nit: assert all_pool.power_status is explicit_pool.power_status in test_pools_for_all_components_share_reference_stores would pin that symptom directly.
4. Nit: the 6-component test relies on the graph-built set printing in a different order than frozenset(ids), which only holds because all_component_ids() now uses a generator. An assert on that premise (or a more general comment) would keep it from silently losing its point.
5. Nit, maybe a follow-up: ReportRequest.get_channel_name() still builds the name from the text of the set; sorting the IDs there would remove the order dependency for good.

[llucax]

🤖 rAIview (AI review here!)

I found no additional issues to raise. Resolving the component IDs before choosing the reference-store key consistently shares state between equivalent pools, while including the store class in the duplicate-warning key keeps different pool types separate. I found no breaking API changes or new security concerns.