diagnostic_bridge: keep DiagnosticStatus key-values as evidence, STALE severity configurable per name

[mfaferek93]

Thread: https://discourse.ros.org/t/why-we-did-not-extend-diagnostics/57859

Problem

A sensor fusion node publishes outlier counts and gate statistics as key-values on /diagnostics. The bridge uses key-values only to pick a code (keyvalue_codes) and drops the rest. The numbers behind the fault never reach the fault record.

The same node goes STALE on purpose (GPS in every blackout, IMU covariance -1). The bridge maps STALE to CRITICAL unconditionally (diagnostic_bridge_node.cpp:201) and CRITICAL skips debounce (fault_storage.cpp:147). Every blackout confirms a CRITICAL fault.

Change

1. On FAILED, pass the status key-values to the fault manager and store them in the fault's freeze frame. keyvalue_codes stays as is. Check ReportFault.srv first, a separate attach-evidence call may be cleaner than a new field.
2. Parameters stale_severity (default CRITICAL) and stale_severity_overrides (name or prefix -> severity). A matching STALE status uses the override and goes through debounce.

Done when

• An ERROR status with key-values rejected_fixes=37, nis=0.03 gives a fault whose snapshot lists both, visible via GET /apps/{app}/faults/{code}.
• stale_severity_overrides: {gps: WARN} makes a STALE gps status report WARN and get debounced. Without an override it stays CRITICAL.
• Unit tests for both parameters, one integration test for the freeze frame, bridge README updated.

Out of scope: checks on the key-values themselves (#669), a "never reported" state for missing sources.