Starting or stopping a camera recording stops an ongoing multibeam recording

[follesoe]

Describe the bug
RecordCtrl sets the recording state of the main camera, the guest port camera and the multibeam in one message. CtrlClient.set_recording_state() only fills in main and guestport, so record_on.multibeam is always sent as False. Starting or stopping a camera recording from the SDK therefore also stops a multibeam recording that is in progress, for example one started from the Blueye app.

Camera.set_recording() already reads the current state from RecordStateTel so that it doesn't change the other camera, but it doesn't do the same for the multibeam.

To Reproduce

1. Start a multibeam recording, for example from the Blueye app.
2. From the SDK, start or stop a camera recording with drone.camera.set_recording(True) (drone.camera.is_recording = True on v2.7.0).
3. The multibeam recording stops, and multibeam_is_recording in RecordStateTel goes to False.

Found by reading the SDK and drone code, not yet reproduced on a drone.

Related code:

blueye.sdk/blueye/sdk/connection.py

Lines 348 to 358 in d1fbfae

	def set_recording_state(self, main_enabled: bool, guestport_enabled: bool):
	"""Enable or disable recording.
	Args:
	main_enabled (bool): Whether to enable main recording.
	guestport_enabled (bool): Whether to enable guest port recording.
	"""
	msg = blueye.protocol.RecordCtrl(
	record_on={"main": main_enabled, "guestport": guestport_enabled}
	)
	self._messages_to_send.put(msg)

blueye.sdk/blueye/sdk/camera.py

Lines 1033 to 1044 in d1fbfae

	record_state = self._get_record_state()
	if record_state is None:
	logger.warning("Unable to set recording state, no record state telemetry received")
	return
	if self._is_guestport_camera:
	self._parent_drone._ctrl_client.set_recording_state(
	record_state.main_is_recording, start_recording
	)
	else:
	self._parent_drone._ctrl_client.set_recording_state(
	start_recording, record_state.guestport_is_recording
	)

Expected behavior
Starting or stopping a camera recording leaves the multibeam recording state unchanged.

Suggested fix
Handle the multibeam the same way as the other camera: add a multibeam_enabled argument to set_recording_state(), and pass record_state.multibeam_is_recording from Camera.set_recording().

Additional details:

• Affects v2.7.0 (Camera.is_recording setter) and master (Camera.set_recording())
• HEAD commit: d1fbfae

Additional context
The fix still relies on the cached RecordStateTel, so a multibeam recording started just before the call can still be stopped. That race already exists between the main and guest port cameras, and would need a protocol change to avoid completely.