sendspin: forward client_hello.device_info.connections into player + HA

[trudenboy]

sendspin: forward device_info.connections from client/hello into HA's device-registry

Summary

SendspinBasePlayer._refresh_client_info now reads the new
connections: list[tuple[str, str]] | None field on
aiosendspin.models.core.DeviceInfo (added in
Sendspin/aiosendspin#226)
and forwards each tuple verbatim into the player's
device_info.connections set (added in
music-assistant/models#215).
For tuples whose connection_type is "mac" or "bluetooth" the
provider also opportunistically mirrors the value into
IdentifierType.MAC_ADDRESS, so universal_player's cross-protocol
matching can dedupe against AirPlay / Cast / WiiM / DLNA peers that
report the same MAC for the same physical device.

The legacy mac_from_bridge_client_id / is_valid_mac_address
fallback paths stay in place untouched — bridges running pre-aiosendspin
release without connections continue to work via the existing
spb_<mac> client_id route.

Motivation

Empirical evidence on a HA + MA stack: every Bluetooth speaker exposed
via a BT bridge ends up as two device cards in Home Assistant:

Card	connections	Source
MA's media_player.<name>	[] (empty)	This provider
BT bridge integration	{("bluetooth", mac)}	Bridge's HACS / MQTT integration

HA's device-registry can't merge them because there's no shared
connection tuple. The empty-connections half comes from this
provider — _refresh_client_info had no way to surface the BT MAC
because the protocol didn't carry it.

The aiosendspin PR adds the protocol field; this PR consumes it. The
HA core PR forwards MA's device_info.connections into HA's. After
all four PRs land, HA correctly merges the cards.

This is not Sendspin-bridge-specific — any future Sendspin client
that knows hardware identity (AirPlay-via-Sendspin, UPnP-via-Sendspin,
Snapcast-via-Sendspin, custom Zigbee/Thread/Matter bridges) gets
single-card-per-physical-device for free. The connection-type field is
a free-form string by design, so new transports work without taxonomy
changes.

Changes

music_assistant/providers/sendspin/player.py
(SendspinBasePlayer._refresh_client_info):

client_info = hello_payload or sendspin_client.info
preserved_identifiers = dict(self._attr_device_info.identifiers)
preserved_connections = set(self._attr_device_info.connections)  # NEW
self._attr_name = client_info.name
if device_info := client_info.device_info:
    self._attr_device_info = DeviceInfo(
        model=device_info.product_name or "Unknown model",
        manufacturer=device_info.manufacturer or "Unknown Manufacturer",
        software_version=device_info.software_version,
    )
    # NEW: forward connections + opportunistic MAC_ADDRESS mirror
    for conn_type, conn_value in device_info.connections or []:
        self._attr_device_info.add_connection(conn_type, conn_value)
        if conn_type in {"mac", "bluetooth"}:
            self._attr_device_info.add_identifier(
                IdentifierType.MAC_ADDRESS, conn_value
            )
else:
    self._attr_device_info = DeviceInfo()
for id_type, id_value in preserved_identifiers.items():
    self._attr_device_info.add_identifier(id_type, id_value)
for conn_type, conn_value in preserved_connections:  # NEW
    self._attr_device_info.add_connection(conn_type, conn_value)
# Existing legacy block — unchanged. Only fires if MAC_ADDRESS still
# unset, so the new connections-derived MAC takes precedence.
if IdentifierType.MAC_ADDRESS not in self._attr_device_info.identifiers:
    if _mac := mac_from_bridge_client_id(self.player_id):
        ...

Migration impact: universal_player_id will change for affected bridges

For bridges that send connections=[("bluetooth", mac)] AND use a
non-spb_* client_id (e.g. UUIDv5(MAC)),
_get_device_key_from_players previously fell through to the
player_id-based fallback — now it sees MAC_ADDRESS and uses the
MAC. The resulting universal_player_id switches from
up<uuid_no_dashes> to up<mac_no_separators>.

This changes the HA media_player.* unique_id for those
bridges. Existing entities go to unavailable; new entities register
under the new ID. Operators must remove the stale entity from HA's UI
and rebuild dashboards / automations referencing the old unique_id.

This is intentional — _get_device_key_from_players's rank order
(MAC > UUID > fallback) reflects that MAC is more reliable. Once the
chain converges, the same physical speaker dedupes correctly across
protocol-bridge peers (AirPlay + BT + WiiM + …).

The migration cost is one-time. Bridges that don't ship
connections (everyone today) keep working unchanged.

Tests

tests/providers/sendspin/test_device_info.py (11 cases):

1. Bluetooth connection → connections set + MAC_ADDRESS identifier.
2. mac connection → connections set + MAC_ADDRESS identifier.
3. Unknown connection types (zigbee, matter, custom) pass through but
   do not pollute MAC_ADDRESS — mirror restricted to mac/bluetooth.
4. Legacy payload (connections=None) still falls through to
   mac_from_bridge_client_id for spb_* client_ids.
5. Connections-derived MAC takes precedence over spb_<other_mac>
   client_id (set first; legacy block guards on MAC_ADDRESS not in identifiers).
6. Pre-existing identifiers and connections survive _refresh.
7. Multi-connection passthrough: all stored, only mac/bluetooth mirror.
8. MAC normalization across input formats (colon / dash / no separator
   / canonical) — parameterized.

Local-test caveat

The full music_assistant package import chain pulls torch via
music_assistant.controllers.streams.audio_analysis. torch has no
Intel-mac wheel, so SendspinBasePlayer cannot be imported in a
locally-installed venv on Intel macOS. The test file mirrors the
_refresh_client_info body byte-for-byte (with a # NOTE: keep this body in lockstep with… warning) so the upstream Linux runner exercises
the real method while local development still validates the logic.

Captured CI output in .local-ci-output.txt.

Backwards compatibility

• aiosendspin's new connections field is omit_none = True, so old
  clients (no connections key) deserialize cleanly to None. The
  for conn_type, conn_value in device_info.connections or []: guard
  handles None correctly — no crash.
• The legacy mac_from_bridge_client_id / is_valid_mac_address
  fallback paths run unchanged whenever MAC_ADDRESS isn't already set
  by the new connections-derived path. Bridges without connections
  keep their spb_<mac> extraction.

Coordination

Depends on:

• music-assistant/models#215
  — DeviceInfo.connections field on the player model + add_connection() helper.
• Sendspin/aiosendspin#226
  — protocol-level DeviceInfo.connections field.

Companion:

• home-assistant/core#169541
  — MA integration forwards player.device_info.connections into HA's DeviceInfo.

Umbrella discussion with full design context and status:
https://github.com/orgs/music-assistant/discussions/5415

This PR cannot land before the music_assistant_models and aiosendspin
releases; targeting dev per project convention.

Test plan locally (full)

./scripts/setup.sh
source .venv/bin/activate
pre-commit run --all-files
pytest tests/providers/sendspin/

(On Intel macOS the music_assistant package import will fail at torch;
the new test file uses a _PlayerStub shim that mirrors the method
body so we can validate the logic without the full import chain.
Linux CI runs the real path.)