Implement Logical BUS_ID Topology for Multi-Gateway Failover

[GreenGrassBlueOcean]

As discussed in PR #459, @anotherjulien proposed using a BUS ID as the primary topology model for multi-gateway setups rather than pinning entities to a single primary gateway's MAC address.

Currently in PR #459, we are shipping a "Phase 1" multi-gateway topology where entities are strictly bound to a single primary gateway unique ID, and failover/standby gateways share that topology.

Proposal:
Migrate the underlying abstraction to a BUS_ID model:

• Entities are bound to a logical BUS_ID instead of a physical gateway MAC.
• Gateways announce which BUS_IDs they have access to.
• Failover and routing become a property of the bus, inherently supporting true N:M topologies rather than strictly Primary-Standby.

Why is this a separate "Phase 2" effort?

Implementing a logical BUS_ID model represents a massive architectural shift that is too large for the current Phase 1 PR:

1. Entity Migration Risk (Breaking Change): In all existing MyHOME installations, entities are registered with a unique ID format of {mac}-{who}-{where}. Moving to a logical bus requires changing this format to {bus_id}-{who}-{where}. This requires complex Home Assistant entity registry migration scripts (�sync_migrate_entries) to carefully port thousands of existing user devices to the new ID scheme without breaking their dashboards, history, and automations.
2. Configuration Flow Rewrite: The current topology engine is built around using the Primary Gateway's MAC address as the anchor for secondary/standby gateways. Shifting to a BUS_ID model means completely redesigning the user interface for the config flow (e.g., asking users to create or name a "Bus" and assign gateways to it) and rewriting the internal routing logic.
3. Test Suite Invalidation: PR feat(gateway): multiple gateway and shared bus support (#453) #459 includes over 4,100 lines of code with 100.0% test coverage. Changing the fundamental topology model would invalidate the massive est_multi_gateway.py suite we just finalized, requiring a significant rewrite of the test infrastructure.

By splitting this out, we can ship stable failover capabilities to users immediately in Phase 1, and handle the high-risk database migrations for BUS_ID in a carefully isolated Phase 2 PR.

[anotherjulien]

Yeah... it's a bit late in the game to have such a stupid idea 😁

To cover my reasoning:

• Having the gateway's MAC as root of every device's UID, there is an underpinning link between the device and the gateway through which it was first discovered.
  It's all and fine for a single gateway setup, but it conceptually fails with multiple gateways connected and used together on the bus.
• Introducing the concept of named buses in the UI would allow multiple gateway to seamlessly work on the same bus, with devices having a bus as a UID root.
  It would also allow users to know which bus they are acting on, if the chosen bus name is displayed somewhere.
• If we support multiple buses, there will still be a need to internally know which bus is connected to which device and which gateway. So the bus concept still needs to happen under the hood.
  This proposal brings the concept front and center, as opposed to tacked-on.

And for the rebutal:

• We can conceptually treat the first gateway used to connect to a bus as a BUS_ID of sorts (a number's a number...)
• Internally we use the device's MAC as a BUS_ID, and still surface the UI to name that bus and so on...
• Only drawback to this idea: if you have a gateway first used to connect "bus 1", then add another gateway to "bus 1", then repurpose the first gateway to create and connect a new "bus 2".
  That would mean both "bus 1" and "bus 2" end up with the same gateway 1 MAC as UID root.
  If that is a scenario we want to explicitly consider, is an open question.

[anotherjulien]

Quick idea to ease migration:
We could consider the existing primary gateway's MAC as a sort of "Legacy BUS_ID".
So new busses would be added with a generated ID, and the drawback of repurposing a gateway for another bus will not be one.

For people currently running multiple gateways on multiple buses, then all would become "Legacy BUS_ID" and not change.
However, for people with multiple gateways on the same bus, only the primary one would become "Legacy BUS_ID"