feat: per-fault_code debounce threshold configuration

[bburda]

Summary

PR #274 adds per-entity debounce thresholds (longest-prefix matching on source_id). This works well when subsystems have distinct fault codes, but has a subtle limitation: the debounce counter is per-fault_code, while config resolution is per-source_id. When two entities with different configs report the same fault_code, the last reporter's config determines the status transition - bypassing the other entity's debounce policy.

Per-fault_code threshold configuration would complement per-entity thresholds by mapping directly to how faults are stored (each fault_code has its own counter), avoiding cross-entity interference entirely.

---

Proposed solution (optional)

Add a fault_thresholds section to the entity thresholds YAML config (or a separate file) that maps fault codes to debounce overrides:

# fault_thresholds.yaml
MOTOR_OVERHEAT:
  confirmation_threshold: -5
  healing_threshold: 10
LIDAR_FAIL:
  confirmation_threshold: -1
  healing_threshold: 1

Resolution priority: fault_code override > entity override > global default.

This would reuse the existing DebounceConfig/EntityDebounceOverride infrastructure. The resolver would check fault_code first (exact match), then fall back to the existing source_id longest-prefix matching.

---

Additional context (optional)

• Relates to Per-entity confirmation and healing thresholds #269 and PR feat: per-entity confirmation and healing thresholds #274
• Per-entity thresholds are useful when you don't know fault codes ahead of time but know which subsystems are noisy
• Per-fault_code thresholds are useful when you know your fault codes and want precise control without cross-entity interference
• Both approaches can coexist

[mfaferek93]

Good idea - per-fault_code thresholds would cleanly avoid the cross-entity interference problem since the counter and config operate at the same level.

A few thoughts on implementation:

Timing: I'd do this as a follow-up after #274 merges rather than expanding that PR's scope. The current flat YAML format (entity prefixes) is forward-compatible - we can extend it without breaking existing configs.

YAML format: Two options:

1. Single file with two sections (entity_prefixes: / fault_codes:) - cleaner but changes feat: per-entity confirmation and healing thresholds #274's format
2. Separate fault_thresholds.config_file parameter - zero impact on existing config

I'd lean toward option 1 in a follow-up PR. The resolver already has the infrastructure - adding a fault_code exact-match lookup before prefix matching is ~20 lines of code.

Priority order fault_code > entity prefix > global makes sense. Fault_code is an exact match (you know precisely what you're configuring), entity prefix is a heuristic.

Practical note: The cross-entity case this solves (two entities reporting the same fault_code with different configs) is an edge case in practice - fault codes tend to be subsystem-specific (MOTOR_OVERHEAT, LIDAR_BLOCKED). But having per-fault_code config is independently useful even without the cross-entity problem - it gives operators precise control when they know their fault codes upfront.

Related: #276 tracks a startup warning for the cross-entity case as a shorter-term mitigation.