No way to require a condition to persist before a detection rule raises a fault

[bburda]

Summary

There is no way to make a bridge ride out a single noisy sample before it raises a fault.

The fault_manager debounce counts events, so it can only filter for a reporter that repeats them.
A bridge that evaluates a sampled value and reports on the transition sends one EVENT_FAILED per
raise, and raising confirmation_threshold for it just holds the fault in PREFAILED, which the
default CONFIRMED-only fault list never shows. Pairing that with auto_confirm_after_sec is worse:
HEALED is latched, so at -2 the second occurrence of a fault code never confirms again.

So the filter has to sit where the samples are, and today it cannot:

• The alarm surface in a node map is threshold / above_threshold / fault_code / severity /
  message, plus the status-word and fault-enum forms. Nothing time- or count-based.
• fault_detection.hpp's evaluate() is a pure function of (value, rule), deliberately, so it
  has nowhere to keep a count or a timestamp. FaultTransitionTracker behind it stores one bool
  per fault code.

The result is that one bad reading raises a real fault, and the only thing that can absorb it is
the operator.

Proposed solution

Add a raise qualifier to the shared detection model, so a rule can require a condition to hold
before it becomes an edge. Either form works and both belong in ros2_medkit_fault_detection so
every bridge inherits it rather than growing its own:

• N consecutive evaluations agreeing, or
• a minimum duration the condition has been continuously true.

There is already a good precedent for the second: the comms-loss path in each bridge keeps a
disconnected_since_ timestamp and only raises once the link has been down for the whole window,
so a shorter blip never raises at all. That is exactly the shape wanted here, applied to value
alarms rather than only to the connection.

Bridges would expose it per rule in the node map, and the value should be derived from how often
that bridge samples.

Additional context

This is the part of the debounce story that cannot be configured. The event-counting side is
documented in #642 and its PR; this issue is the missing lever, not a duplicate of it.