Function classify_complexity_attribution 

pub fn classify_complexity_attribution(
    findings: &[HealthFinding],
    root: &Path,
    base: &ComplexityBaseline,
) -> Vec<ComplexityClass>

Classify each head complexity finding against one base, in report order.

Head and base findings match by identity key. When one key holds several findings on one side (same-named class methods or anonymous functions in one file), the match is ambiguous. This conservative rule then applies, per key:

1. Each head finding, in line order, takes an unmatched base finding with the same complexity values and the same line count.
2. Each remaining head finding, in line order, takes an unmatched base finding with the same complexity values. Rules 1 and 2 keep unchanged findings inherited when a same-named finding is added, removed or edited. Rule 1 runs for all head findings first, so an earlier head finding cannot take the exact match of a later one.
3. The remaining head findings, in line order, take the remaining base findings, in line order. Each pair compares the exceeded metrics.
4. A head finding without a base finding is introduced.

Every base finding matches at most one head finding, so a new same-named finding cannot hide behind an existing one. The rule does not identify functions beyond path and name (see #2010). Two same-named findings that swap their metric values in one change stay inherited.

Each matched pair also lists the measured metrics that grew, so an inherited finding that got worse is visible.