Bluetooth: Controller: ISO: Retry sync to BIG after incorrect broadcast code only provides a single SDU

[Thalley]

Describe the bug
If an application provides the incorrect broadcast code when syncing to an encrypted BIG, then retrying with the correct code correctly syncs to the BIG but only a single SDU per BIS is received.

To Reproduce
Steps to reproduce the behavior:

1. Checkout tests: Bluetooth: BAP: Add retry with correct broadcast code #77642
2. Build and run https://github.com/zephyrproject-rtos/zephyr/blob/main/tests/bsim/bluetooth/audio/test_scripts/bap_broadcast_audio_encrypted.sh
3. See error only a single SDU received and the test fails

Expected behavior
Expect that providing the correct code after a sync failure will work. Resyncing to a BIG generally works if both attempts work.

Impact
Seems to be an irreversible state from the host, so quite significant.

Logs and console output

d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: hci_le_big_sync_established: BIG[0] 0x825b620 sync established, status 0x00 
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: bt_iso_connected: 0x825b2a0
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: bt_iso_chan_set_state_debug: chan 0x825ff40 iso 0x825b2a0 connecting -> connected
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_bap_broadcast_sink: broadcast_sink_iso_connected: stream 0x82535c0
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_bap_broadcast_sink: broadcast_sink_set_ep_state: ep 0x8262600 id 0x00 qos-configured -> streaming
d_01: @00:00:22.825207  Stream 0x82535c0 started
d_01: @00:00:22.825207  Could not get octets per frame: -61
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: bt_iso_connected: 0x825b37c
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_iso: bt_iso_chan_set_state_debug: chan 0x825ffd0 iso 0x825b37c connecting -> connected
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_bap_broadcast_sink: broadcast_sink_iso_connected: stream 0x8253604
d_01: @00:00:22.825207  [00:00:22.825,195] <dbg> bt_bap_broadcast_sink: broadcast_sink_set_ep_state: ep 0x826276c id 0x00 qos-configured -> streaming
d_01: @00:00:22.825207  Stream 0x8253604 started
d_01: @00:00:22.825207  Could not get octets per frame: -61
d_01: @00:00:22.825207  Waiting for data
d_01: @00:00:22.837789  [0]: Incoming audio on stream 0x82535c0 len 30 and ts 22830022
d_01: @00:00:22.837789  [0]: Incoming audio on stream 0x8253604 len 30 and ts 22830022
d_00: @00:00:23.107790  Sent with seq_num 2300
d_00: @00:00:23.107790  Sent with seq_num 2300
d_00: @00:00:24.107790  Sent with seq_num 2400
d_00: @00:00:24.107790  Sent with seq_num 2400
d_00: @00:00:25.107790  Sent with seq_num 2500
d_00: @00:00:25.107790  Sent with seq_num 2500
d_00: @00:00:26.107790  Sent with seq_num 2600

Environment (please complete the following information):

• Commit SHA or Version used: eaf92a1

Additional context
N/A

[Thalley]

We may actually just be unable to resync to encrypted broadcast source regardless of whether the broadcast code is correct or not, as #75491 is failing to a similar of the same issue

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[Thalley]

This seems to have been fixed at some point - At least the above PR is now passing. Closing the issue