Allow players to change supported_commands mid-session

[maximmaxim345]

supported_commands was split across two messages, 'volume' and 'mute' in the client/hello support object and 'set_output_delay' in client/state, so a player could not change which commands it accepts without reconnecting and server/command had to name both locations as sources of truth. The whole list moves into the client/state player object.

The split also failed silently: an SDK reading only client/hello ignores set_output_delay, one reading only client/state ignores volume and mute, and neither errors. Consolidating matches the CONTRIBUTING rule that a field expected to change during a connection belongs in client/state.

This breaks player@v1 on the wire, and a server can no longer see command capabilities at server/activate time, which is exotic but worth stating.

#175 already made supported_commands non-optional and defined an empty list as accepting no commands, so the field line itself only gains 'volume' and 'mute', and the client/hello copy is deleted.

Rules the move requires

A server MUST NOT send a player command before the client has sent a client/state containing the player object, mirroring the existing rule for binary data. The move opens that window because server/activate precedes the first state message, and the player object is the unit that carries supported_commands.

supported_commands advertises settability, not reportability. A player MAY report volume or muted without accepting the matching command, an amplifier with a physical volume knob being the real case, and capability cannot be inferred from field presence because output_delay_ms is never optional either way. A server MUST NOT treat a reported volume or muted as settable while the matching command is absent, though it MAY still surface the value read-only.

Group volume averages over volume-capable players, so when the last capable player withdraws the reported value jumps to 100 and the control disappears with nobody having touched a volume. Both reading rules now say so and require a recompute when a player's support changes.

Group volume writes

The group volume algorithm already disagreed with itself before this change: it computed its delta against the average of all player volumes and sent a command to every player, while the reading rules excluded players without volume support. The move makes the mismatch reachable mid-session, so both paths now filter on capability, and setting group mute gets the same fix. This part is separable if you would rather it went on its own.

Editorial

The "Server behavior" bullets sat under the client/hello support-object heading while describing required_lead_time_ms and min_buffer_ms, which live in client/state, and two cross-references pointed at that mismatched anchor. The text merges into "Server Audio Send Constraints", which already carries the overlapping lead and send-ahead rules.

Closes #142

[arturpragacz]

Weren't we supposed to align all dynamically changing values and move them all to client/state? So including for example visualizer's and artwork's stream/request-format fields.

[maximmaxim345]

Weren't we supposed to align all dynamically changing values and move them all to client/state? So including for example visualizer's and artwork's stream/request-format fields.

Thats for a different PR though since it touches multiple roles, I'll write that once #175 is merged.

[kahrendt]

Thanks!