Add dual-battery telemetry and drone PowerSource

[follesoe]

Summary

Prepares the protocol for X7 configurations that can run two batteries in parallel, and lets clients learn the drone's power configuration up front (without waiting for telemetry).

Location	Change
BatteryTel (telemetry.proto)	Added Battery second_battery = 2 for the second parallel battery
BatteryBQ40Z50Tel (telemetry.proto)	Added BatteryBQ40Z50 second_battery = 2 for the second parallel battery
PowerSource enum (message_formats.proto)	New enum: UNSPECIFIED / SINGLE_BATTERY / PARALLEL_BATTERIES
DroneInfo (message_formats.proto)	Added PowerSource power_source = 13

Second battery

second_battery reuses the existing types (Battery / BatteryBQ40Z50) so the second battery reports the same information as the first. It has message presence in proto3, so on single-battery drones it is simply left unset — documented on both messages.

message BatteryTel {
  Battery battery = 1; // Essential battery information.
  Battery second_battery = 2; // Second battery, when present. Not set if only one battery is used.
}

PowerSource enum

enum PowerSource {
  POWER_SOURCE_UNSPECIFIED = 0; // Power source unknown / not determined.
  POWER_SOURCE_SINGLE_BATTERY = 1; // A single battery.
  POWER_SOURCE_PARALLEL_BATTERIES = 2; // Two batteries running in parallel (e.g. X7).
}

Exposed via DroneInfo.power_source (field 13) so clients can determine the power configuration (parallel batteries on the X7) directly from DroneInfo. The enum is intentionally extensible — e.g. a future POWER_SOURCE_TOPSIDE for topside power.

• Zero value is named POWER_SOURCE_UNSPECIFIED to follow the repo's enum convention (and proto3 best practice); its comment documents the "unknown / not determined" meaning.

Validation

• protolint passes
• protoc compiles cleanly
• DroneInfo field numbers verified unique/contiguous (1–13)

Notes

• No existing fields changed → wire-compatible.
• No package version bump included in this PR (let me know if one is wanted for publishing).
• Downstream consumer libraries / firmware will need regenerated bindings to use the new fields.

🤖 Generated with Claude Code