Debounce profile leaves the goal-status faults permanently unconfirmed

[bburda]

Summary

In the TurtleBot3 demo, the debounce profile hides two of the three faults the demo can raise.

config/medkit_params_debounce.yaml sets confirmation_threshold: -3. That fits the no-progress
check, which repeats every five seconds while the robot is stuck, so three reports arrive and the
profile filters roughly fifteen seconds of it. That is the contrast the demo is built around.

The other two do not repeat. NAVIGATION_GOAL_ABORTED and NAVIGATION_GOAL_CANCELED are raised
from a goal status change, guarded by if last_status != status.status, so exactly one FAILED
arrives, and one PASSED when a later goal succeeds. The debounce counter reaches -1 and stops, so
both stay PREFAILED. ListFaults with no status filter returns CONFIRMED only, so neither ever
reaches an operator. auto_confirm_after_sec is 0 in that profile, so nothing promotes them later.

Measured against a running fault_manager with the profile's own values:

one FAILED           PREFAILED, counter -1
after 3 s of silence PREFAILED, counter -1
one PASSED           PREFAILED, counter  0

Two smaller things on the same files:

• The same profile pairs healing_threshold: 3 with a comment saying three PASSED events heal.
  Healing costs healing_threshold minus the counter at recovery, so from -3 it takes six, and the
  detector sends one. Healing never happens.
• config/medkit_params.yaml sets confirmation_threshold: 0. The fault manager rejects a
  non-negative threshold and replaces it with -1, logging a warning.

Proposed solution

Report the goal-status faults under their own source_id and give that source its own thresholds
through a per-source file: -1 to confirm on the single event, 0 to heal on the single clear. The
no-progress fault keeps the global -3, so the storm-versus-filtered contrast the demo exists to
show is unchanged.

Set healing_threshold to 0 in the debounce profile and confirmation_threshold to -1 in the
storm profile.