Mavlink: update MAG_CAL_STATUS failure enums

[christianpetri]

Context

AP_Compass: report specific failure reason when fit rejected (ardupilot#32757) extended ArduPilot's compass calibrator to emit a specific failure code in MAG_CAL_REPORT.cal_status instead of always returning the generic MAG_CAL_FAILED. Three new status values were added (8 = FAILED_OFFSETS, 9 = FAILED_DIAG_SCALING, 10 = FAILED_RESIDUALS_HIGH).

That required the MAVLink spec and every toolchain downstream of it to be updated:

1. mavlink/mavlink#2478 — common.xml: rename MAG_CAL_BAD_ORIENTATION → MAG_CAL_FAILED_ORIENTATION, MAG_CAL_BAD_RADIUS → MAG_CAL_FAILED_RADIUS, add FAILED_OFFSETS / FAILED_DIAG_SCALING / FAILED_RESIDUALS_HIGH. Merged Jun 2.
2. ArduPilot/mavlink#506 — Sync the same change into the ArduPilot MAVLink fork. Merged 2 weeks ago.
3. ardupilot#33642 — Bump the ArduPilot mavlink submodule pointer to pick up the new enums. Merged 2 weeks ago.
4. This PR — Apply the same common.xml change to Mission Planner's vendored copy and update the generated Mavlink.cs enum block, so the GCS shows descriptive names instead of raw integers.

Changes

• ExtLibs/Mavlink/message_definitions/common.xml — apply the 17-line diff from common: rename/add MAG_CAL_STATUS failure enums to FAILED_* + RESIDUALS_HIGH mavlink/mavlink#2478
• ExtLibs/Mavlink/Mavlink.cs — update the MAG_CAL_STATUS enum block to match

No other files are touched.

Verification

dotnet build MissionPlanner.csproj -c Debug succeeds with 0 errors.

[tridge]

Automated review note — AI-generated (Claude), validated against the live diff. Please sanity-check before acting.
Full report: https://uav.tridgell.net/DevCallReviews/2026_08_30/devcall_pr_reviews.html#prMissionPlanner-3750

Reviewed at head 390efc38f9. APPROVE — no blockers.

The main risk with a vendored common.xml is quietly diverging from upstream, so that's what I checked: the resulting MAG_CAL_STATUS block is byte-identical (same SHA-256 after CRLF normalisation) to both mavlink/mavlink master and ArduPilot/mavlink master. No wire values are renumbered — 0–5 untouched, 6 and 7 renamed, 8/9/10 appended. Mavlink.cs matches the XML 1:1 in names, values, order and description formatting, and regenerating with the vendored mavgen produces an identical enum block (differing only in MAVLINK_BUILD_DATE), so the hand edit is generator-exact. ArduPilot firmware agrees: CompassCalibrator.h explicitly assigns 8–10. Nothing in MissionPlanner switches on these names — ConfigHWCompass.cs and ConfigHWCompass2.cs just stringify the cast and compare against MAG_CAL_SUCCESS — so the renames break nothing and statuses 8–10 now display as names instead of bare integers, which is exactly what you claimed.

One loose end and two notes:

1. ISSUE — ExtLibs/Mavlink/mavlink.lua:2080-2089 is left stale. regenerate.bat generates the Wireshark dissector from the same XML, and it's now the only file in the tree still carrying MAG_CAL_BAD_ORIENTATION/MAG_CAL_BAD_RADIUS and missing 8–10. Regenerating the WLua output changes only that enum. Wireshark-only, no runtime effect — worth a one-line follow-up commit rather than blocking.
2. NOTE. Renaming public C# enum members is source-incompatible for out-of-tree consumers referencing the old names. Wire values and in-tree code are unaffected and matching upstream is clearly right — just worth a release-note line.
3. NOTE. CI has never run on this PR (all three workflows are action_required with zero jobs), so the build is unverified by anything but your local dotnet build. My approval is on reading the change, not on a green tick.