Add OperatorInfo message to track dive operator

[follesoe]

Summary

• Adds a new OperatorInfo message in message_formats.proto with name and email fields to identify the operator controlling the drone.
• Adds an optional operator field to StartDiveCtrl in control.proto, so dive logs capture who started each dive.
• Enables downstream use in reporting and when importing dives to Blueye Cloud.

Test plan

• Verify proto files compile successfully (CI protolint + builds)
• Confirm existing clients without operator info still work (field is optional in proto3)
• Verify the new message appears in generated TypeScript, C#, and Python libraries

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds operator attribution to the control/logging protocol by introducing an OperatorInfo message and attaching it to StartDiveCtrl, enabling dive logs (and downstream imports) to record who initiated a dive.

Changes:

• Added new OperatorInfo proto message with name and email.
• Extended StartDiveCtrl with an operator field carrying OperatorInfo.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
protobuf_definitions/message_formats.proto	Introduces OperatorInfo shared message for identifying a dive operator.
protobuf_definitions/control.proto	Adds operator metadata to StartDiveCtrl for inclusion in logs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[aviggen]

How would the user pick the operator? Is it only when the user is logged in in the app?

[follesoe]

We can choose. It would be two string settings stored locally, that the user can set: Default Operator Name, and Default Operator Email.

After Blueye Cloud, we will get it from the signed in user. This will solve the case where say Trond does dives with a drone, and someone else synchronizes it, then in the Blueye Cloud, we can assign the operator automatically during ingestion.