ros2_medkit_msgs: propagate Condition Quality (StatusCode) through fault lifecycle

[mfaferek93]

Motivation

OPC-UA Part 4 §7.34 and Part 9 §5.5.2.5 define a per-condition Quality field (StatusCode: Good / Uncertain / Bad) that signals whether the underlying signal that produced an alarm is itself reliable. Without it, an operator cannot distinguish a confirmed fault on a healthy sensor from a possible-fault on a degraded one - the UI shows both as "OVERPRESSURE CRITICAL".

The bridge added in #386 reads Quality from each event but currently drops it on the floor before the fault_manager call. This issue tracks propagating it end-to-end so SOVD clients (and sovd_web_ui) can render and filter on it.

Scope

• Additive uint8 status_quality on ReportFault.srv (Request) with constants QUALITY_GOOD = 0 / QUALITY_UNCERTAIN = 1 / QUALITY_BAD = 2. Default 0 keeps every existing reporter binary-compatible.
• Same field on Fault.msg so the SOVD JSON response surfaces it without a separate serializer.
• FaultStorage::report_fault_event signature accepts the new value (default QUALITY_GOOD for backward compat).
• InMemoryFaultStorage carries it on the FaultState and returns it in list_faults / get_fault.
• SqliteFaultStorage adds an additive column with a forward-only migration: existing rows default to QUALITY_GOOD on first read; new rows persist the actual value.
• fault_manager_node passes request->status_quality through to the storage call.
• ros2_medkit_opcua plugin reads the OPC-UA Quality field from the event payload (already in the EventFilter select clauses) and maps it to the new SOVD enum.
• SOVD response builders (handlers/fault_handlers.cpp) render the field in GET /faults and GET /faults/{code}.
• sovd_web_ui: badge / icon for non-GOOD quality (separate sub-issue if UI work splits naturally).

Acceptance criteria

1. Existing fault reporters (without status_quality set) continue to work unchanged - their faults are stored with QUALITY_GOOD.
2. An OPC-UA event carrying Quality = Bad produces a SOVD fault whose JSON response contains "status_quality": "BAD".
3. Restarting the gateway reloads persisted faults with their original status_quality from SQLite.
4. GET /faults?status_quality=BAD filters to only degraded-signal faults (filter param accepted at the SOVD layer).

Out of scope

• Severity downgrade rules tied to quality (e.g., "demote CRITICAL to ERROR when Quality=Bad"). The two dimensions stay independent at the data layer; the UI can apply its own visual rule.
• Quality-driven debounce changes.

References

• OPC UA Part 4 §7.34 (StatusCode): https://reference.opcfoundation.org/Core/Part4/v105/docs/7.34
• OPC UA Part 9 §5.5.2.5 (Quality field on ConditionType): https://reference.opcfoundation.org/Core/Part9/v105/docs/5.5.2.5
• AUTOSAR DEM DTC.Status.warningIndicatorRequested is the closest automotive analogue (separate severity / quality flags)
• Bridge that currently drops the field: ros2_medkit_opcua: subscribe to native OPC-UA AlarmConditions and bridge to fault_manager #386 (event payload parsing in OpcuaPoller::on_event)