feat: consume vehicle-provided parameter metadata

[JackSkellet]

Summary

This adds support for consuming parameter metadata published by the connected flight controller instead of relying exclusively on BlueOS's bundled ArduPilot metadata files.

The implementation:

• receives MAVLink COMPONENT_METADATA advertisements;
• downloads bounded parameter metadata documents over MAVFTP or HTTPS;
• validates the advertised CRC and document structure;
• exposes the active document from ArduPilot Manager with ETag support;
• merges vehicle-provided metadata over the nearest compatible bundled metadata in the frontend;
• refreshes the table when the vehicle advertises a new metadata generation;
• keeps bundled fallback selection within the same vehicle family;
• upgrades mavlink2rest from t0.11.25 to 1.0.2 and adapts BlueOS consumers to its string and bitflag JSON representation.

Why

BlueOS currently assumes that parameter names, descriptions, units, ranges and enum choices are fully described by a static metadata file bundled with the frontend. That does not work well for custom firmware or for parameter choices that depend on devices discovered at runtime.

This enables use cases such as:

• custom or development firmware supplying descriptions for parameters that do not exist in an upstream ArduPilot release;
• detected sensors being presented as meaningful enum choices without a BlueOS-specific override;
• per-lane EKF source-target selection, for example selecting different DVLs for EK3_SRC1, EK3_SRC2 and EK3_SRC3;
• refreshing source-target choices when sensors are attached, removed or replaced;
• vehicle-specific parameter descriptions, units, defaults, ranges, bitmasks and enum labels;
• continuing to use bundled ArduPilot metadata when a vehicle does not publish component metadata.

The live metadata overlay has exact-name priority and also supports parameter templates. Invalid documents fail closed and do not replace the last valid snapshot.

Parameter import reliability

The parameter loader is also made tolerant of parameter files from another firmware version or feature set:

• parameters absent from the connected vehicle are skipped instead of blocking the whole import;
• PARAM_SET uses the live parameter's MAVLink type;
• rejected values stop retrying after the existing bounded retry budget and are reported as skipped;
• retry timers and state are cleaned up when the dialog completes or closes.

This allows a useful subset of a parameter file to be applied without leaving the loader permanently failed because optional parameters are unavailable.

mavlink2rest compatibility

COMPONENT_METADATA is not available through the previously pinned mavlink2rest release. Version 1.0.2 provides the required message definitions but changes the JSON representation of MAVLink character arrays and bitflags.

The frontend and Commonwealth compatibility changes cover incoming and outgoing PARAM_*, STATUSTEXT, HEARTBEAT and related message paths so the upgrade does not silently break existing consumers. Release artifacts were checked for x86_64, ARMv7 and AArch64.

Additional operational fixes

Two separate commits from live BlueOS testing are included in this draft:

• disable Sentry source-map upload when credentials are not configured;
• JSON-serialize Commander environment-variable responses so the frontend does not receive [object Object].

They fix startup/UI failures encountered while validating this branch. They are kept as separate commits and can be split into follow-up PRs if preferred.

Validation

• ArduPilot Manager parameter-metadata tests: 10 passed.
• Frontend metadata and mavlink2rest compatibility tests: 8 passed.
• Commonwealth mavlink2rest compatibility tests: 3 passed.
• Targeted ESLint and Stylelint: passed.
• Ruff and Mypy checks for the changed Python paths: passed.
• Frontend production build: passed.
• Official mavlink2rest 1.0.2 artifacts resolved for x86_64, ARMv7 and AArch64.
• Live ARMv7 Raspberry Pi 4 and AArch64 Raspberry Pi 5 testing: BlueOS startup/shutdown, metadata advertisement, MAVFTP retrieval, ETag refresh, fallback selection and parameter-table rendering passed.

[CLAassistant]

All committers have signed the CLA.

[patrickelectric]

@JackSkellet can you rebase the PR over master ?

[JackSkellet]

@patrickelectric rebase has been completed.