Debounce docs recommend a setting that silently disables faults for one-event-per-transition reporters

[bburda]

Summary

The debounce documentation recommends a configuration that quietly does nothing for a whole class
of fault reporters, and the parameter that does work for them is documented but never connected to
the case.

The debounce counter only moves when an event arrives. confirmation_threshold and
healing_threshold therefore assume a reporter that keeps sending FAILED while the condition is
still there, and keeps sending PASSED after it goes away.

Many reporters do not work that way. They send one FAILED when a condition appears and one clear
when it goes away, and nothing in between. The README section "Advanced: Debounce Filtering"
recommends this to everyone:

-p confirmation_threshold:=-3 -p healing_enabled:=true -p healing_threshold:=3

For a reporter of the second kind that gives:

• The second FAILED never arrives, so the counter stops at -1 and the fault stays PREFAILED. It
  never confirms.
• ListFaults with an empty statuses array returns CONFIRMED only, so nobody sees the fault at
  all.
• Healing needs healing_threshold - confirmation_threshold consecutive PASSED events. Only one
  PASSED is ever sent, so a fault that did confirm stays CONFIRMED until someone calls
  ~/clear_fault.

So the recommended setting turns a working fault path into a silent one, and nothing in the docs
warns about it.

auto_confirm_after_sec already solves this. It promotes a PREFAILED fault to CONFIRMED after a
timeout without touching the counter, which is exactly the filter such a reporter needs: hold the
first FAILED in PREFAILED, and confirm it only if it is still there when the window closes. The
docs list the parameter in the table but never say this is what it is for.

There is also no test on this path. No test covers auto_confirm_after_sec, and no test covers
healing_threshold: 0, which is the only value that lets a single PASSED event heal a fault.

Proposed solution

Documentation, in the package README and in docs/config/fault-manager.rst:

• Say that the count-based settings need a reporter that repeats its events.
• Say what happens when they are used with a reporter that sends one event per transition.
• Point at auto_confirm_after_sec plus healing_threshold: 0 as the pair for that case, and say
  the timeout should come from how often the reporter samples.

Test, in ros2_medkit_fault_manager:

An integration test driving the real node over the real services, using the event counts a
one-event-per-transition reporter actually sends. It should pin:

• one FAILED does not confirm
• an unconfirmed fault is not in the default fault list
• a condition that stays raises CONFIRMED after auto_confirm_after_sec with nobody acting
• a condition that clears inside the window never confirms
• one PASSED heals a confirmed fault with nobody acting

The fourth one matters most. Without it a config could pass by only delaying a false alarm instead
of filtering it.

Additional context

No code change is needed. All four parameters already behave correctly, and both storage backends
agree on the arithmetic. This is a documentation gap plus a test gap.