fix: parse multiple audioStreamMode entries in TalkAbility (#371)

[nythtech-nl]

Problem

neolink talk fails for the Reolink Video Doorbell with:

ERROR neolink_core::bc::de] e: Custom("duplicate field `audioStreamMode`")
Error: Camera <name> does not support talk

The doorbell's TalkAbility response advertises two <audioStreamMode> values:

<audioStreamModeList>
  <audioStreamMode>followVideoStream</audioStreamMode>
  <audioStreamMode>mixAudioStream</audioStreamMode>
</audioStreamModeList>

but AudioStreamModeList.audio_stream_mode is a single String, so serde rejects the second element as a duplicate field and neolink wrongly concludes the camera cannot talk.

Fixes #371.

Fix

• Make AudioStreamModeList.audio_stream_mode a Vec<String> (#[serde(default)]).
• Select the first advertised mode when building TalkConfig.

Testing

Built from this branch and ran neolink talk against a Reolink Video Doorbell behind an RLN12W NVR (talk routed via channel_id). Before: "does not support talk". After: TalkAbility parses, the talk pipeline streams, and audio plays from the doorbell speaker. Cameras that advertise a single mode are unaffected (.first() yields the same value).

[josh-stephens]

Confirming this fix works on hardware that hits the bug: Reolink Battery Video Doorbell 2nd Gen (hardware DBB_NT19DNO34MPW6DBB3, firmware v3.0.0.6304_26041428, connected standalone via UID/local UDP discovery).

Before the patch, neolink talk failed at capability negotiation — the doorbell's TalkAbility response lists two audioStreamMode entries (followVideoStream + mixAudioStream) in one audioStreamModeList, producing duplicate field \audioStreamMode`` and the misleading "Camera doorbell does not support talk".

With this patch applied on master, talk negotiates cleanly (FDX, adpcm 16kHz) and audio plays at the doorbell — tested with both webm/opus and mp4/AAC inputs through decodebin. Would love to see this merged.