Add guest port capability model and incompatible-device error flags

[follesoe]

Summary

First step of the X7 guest port work tracked in the design doc BluEye-Robotics/libguestport#383: make the drone the owner of device↔port compatibility by modelling port capabilities and device requirements in the protocol.

Closes #243.

Changes

• New GuestPortCapability enum — ETHERNET, I2C, RS232, RS485, USB2, PWM. Used both for the interfaces a port provides and for the interfaces a device requires.
• GuestPortConnectorInfo.capabilities = 4 (repeated) — the interfaces the physical port provides. Placed outside the connected_device oneof so a port that errors (e.g. NOT_FLASHED) still advertises what it supports.
• GuestPortDevice.required_capabilities = 8 (repeated) — the interfaces the device needs, sourced from peripherals.json in libguestport.
• GuestPortDevice.compatible_guest_ports = 9 (repeated GuestPortNumber) — computed by the drone as the ports whose capabilities cover the device's requirements. Clients derive incompatibility as guest_port_number ∉ compatible_guest_ports and can suggest valid ports.
• ErrorFlags.gp1_incompatible_device = 78 … gp6_incompatible_device = 83 — per-port dive-time warning bits, to be raised by the guest port supervisor.
• rust/build.rs — GuestPortCapability added to the pbjson serde allowlist so the on-drone guest-port JSON carries the new fields.

Design notes

• No GUEST_PORT_ERROR_INCOMPATIBLE_PORT value (as originally floated in Add error flag if a guest port device is connected to an incompatible port #243): GuestPortConnectorInfo reports device_list XOR error via the oneof, and an incompatible device is still a successfully read device — signalling through GuestPortError would discard the device info.
• Deliberately no port role/designation concept and no modelling of the X7's USB-C (USB 3.0) connector, which has no I2C/EEPROM mechanism — see the design doc for rationale.
• Backwards compatible: old clients ignore the unknown fields; new clients fall back to existing behavior when the fields are absent.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR extends the protocol definitions to let the drone report guest-port interface capabilities and device interface requirements, enabling clients to determine (and suggest) compatible ports for a connected device. It also adds per-port “incompatible device” warning bits to ErrorFlags, and updates Rust pbjson generation to include the new enum in on-drone guest-port JSON.

Changes:

• Added GuestPortCapability enum and introduced capability/requirement fields on GuestPortConnectorInfo and GuestPortDevice.
• Added ErrorFlags.gp{1..6}_incompatible_device warning bits (tags 78–83) to signal capability mismatch per port.
• Updated rust/build.rs pbjson allowlist to include .blueye.protocol.GuestPortCapability so the new fields can round-trip via JSON.

Reviewed changes

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

File	Description
protobuf_definitions/message_formats.proto	Adds GuestPortCapability, device-required capabilities, compatible port list, port capabilities, and new incompatible-device error flags.
rust/build.rs	Adds GuestPortCapability to the pbjson serde allowlist for guest-port JSON serialization/deserialization.

---

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