feat: add connection lifecycle events and auto-resume for Sendspin players

[foobarth]

What does this implement/fix?

Problem

When an iPhone (or other mobile Sendspin client) loses its network
connection (tunnel dropout, airplane mode, elevator, WiFi handoff),
the MA server detects the WebSocket disconnect and stops playback
immediately. When the client reconnects within the cleanup window
(300s, up from upstream's 30s), the player is already in "stopped"
state, the user has to manually press play.

For unintended drops shorter than 5 minutes there is no reason to force a
manual resume; the server should recognize the reconnect and
automatically continue playback, if it was playing before the dropout
and the disconnect reason was clearly an unintended network issue.

In the area where i live, 30s is sometimes just not enough and having
to grab the phone while driving, opening the app and restarting playback
is both dangerous and unexpected from a "proper" music player these days.

Solution

Two layers of changes. This PR (MA server) and a companion PR on
aiosendspin (Sendspin/aiosendspin#…):

Sendspin/aiosendspin companion PR#288

• ClientConnectedEvent, ClientDisconnectedEvent fire on every
  connection establish / teardown (not just first-add)
• ClientReconnectedEvent fires when a known client reconnects
  with unchanged hello payload (gap in upstream: ClientUpdatedEvent
  only fires on hello change, so 99% of reconnects were silent)
• GoodbyeReason.CONNECTION_LOST distinguishes unexpected network
  drops from intentional shutdowns
• CLIENT_CLEANUP_DELAY 30s → 300s gives mobile clients a longer
  window to reconnect before being evicted from the registry

This PR (MA server)

New event handlers in Sendspin provider:

• _handle_client_disconnected immediately captures _was_playing
  state and marks player as unavailable for the UI, instead of
  waiting 300s for ClientRemovedEvent
• _handle_client_connected refreshes player info on every
  transport connect (existing player or fresh reconnect)
• _handle_client_reconnected triggers auto-resume via the
  existing _auto_resume_after_reconnect() in player.py

Player enhancements:

• _was_playing flag survives across WS disconnects; set True on
  play_media(), cleared only after successful resume()
• disconnect_behaviour set to UNGROUP (keep player alive during
  drop, avoid cancelling the session)
• Guard _on_group_stopped to not cancel the playback session
  during the reconnect window (race condition with aiosendspin's
  automatic ControllerStopEvent after reconnect)
• GoodbyeReason.CONNECTION_LOST is handled as a warm disconnect
  (roles preserved, cleanup scheduled with delay)

Behaviour

Drop duration	Before	After
<= 300 s	Playback stops, manual resume needed	Auto-resume on reconnect
> 300 s	Client evicted, manual start needed	Manual play (expected — session timed out)

Testing

Live-tested on K8s cluster with custom CI image. Scenarios:

• 3 minute airplane mode -> auto-resume within seconds of reconnect
• 1 minute tunnel dropout -> same
• 5+ minute dropout -> client reconnects but stays paused (expected)

Companion PR

Sendspin/aiosendspin PR#288 must be merged first (or simultaneously)
since the MA code depends on the new events and GoodbyeReason.

Related issue (if applicable):

• Loosely related to !326:

Types of changes

• Bugfix (non-breaking change which fixes an issue) — bugfix
• New feature (non-breaking change which adds functionality) — new-feature
• Enhancement to an existing feature — enhancement
• New music/player/metadata/plugin provider — new-provider
• Breaking change (fix or feature that would cause existing functionality to not work as expected) — breaking-change
• Refactor (no behaviour change) — refactor
• Documentation only — documentation
• Maintenance / chore — maintenance
• CI / workflow change — ci
• Dependencies bump — dependencies

Checklist

• The code change is tested and works locally.
• pre-commit run --all-files passes.
• pytest passes, and tests have been added/updated under tests/ where applicable.
• For changes to shared models, the companion PR in music-assistant/models is linked.
• For changes affecting the UI, the companion PR in music-assistant/frontend is linked.
• I have read and complied with the project's AI Policy for any AI-assisted contributions.
• I have raised a PR against the documentation repository targeting the main or beta branch as appropriate.

[foobarth]

Lint / test issues are expected due to the required companion PR for Sendspin/aiosendspin#288

[OzGav]

Keeping this as draft until the tests can pass.