Hierarchy prefix inference picks the wrong copy of a replicated module when scored candidates tie

Situation: a waveform viewer maps dump paths (tb.dut.u_core1.u_a.x) to the elaborated design (soc.u_core1.u_a.x) by inferring a prefix rule. It scores candidate design roots by how many child names overlap with a dump scope's children, then keeps the best score, using strict '>' so the first candidate wins a tie.

Bug: once roots below the top-level instances are added as candidates (so a dump scope named after a deeper instance can match), the copies of a replicated block (u_core0, u_core1) score the same and outscore the top, because they have more child instances. On the tie, the first key in sort order wins, so a row of core1 gets named and modelled as core0. The values still look right, because the dump prefix is correct, which hides the bug. Only the design-side name and model (parameters) are wrong.

Fix: keep every candidate rule grouped by score. Return the highest score that exactly one rule has, and treat a tie as ambiguous. A shallower root containing both copies (the top, or tb.u_dut) then wins with a wider rule, which also maps fan-in that leaves the core through its ports. Test with two identical sub-instances in both the renamed-top and deeper-instance layouts.

General lesson: when you widen a candidate set, revisit the tie-break. 'First in sorted order' was harmless with only a few top-level roots, but it is wrong with replicated instances.