Mapping instances between two elaborators (e.g. slang vs a vendor KDB): test with a perturbation sweep, never fall back to a same-module sibling

If a tool joins its own elaborated hierarchy against another tool's (a vendor compiled database, a second parser), a failed name lookup is often 'repaired' by picking the nearest instance of the same module type, or by breaking ties with a heuristic. That silently attaches results to the wrong copy: gen[3] maps to gen[0], or u_dut maps to a sibling u_other of the same module. Because the values come from a real instance they look plausible, and a test on unchanged designs never catches it, since both sides agree there.

What worked: 1) If the module chain matches down to some depth and then fails, return 'other module / unknown' at that point. Do not descend into a stand-in. 2) Below a matched counterpart, accept only the identical relative path. 3) Check the module chain of any fallback answer against the other database before you trust it. 4) Test with a perturbation sweep over generated designs: remove a subtree, change one instance's module, rename an instance. For each mode, count rows whose answer differs from the ground truth. The no-database path should stay at 0 wrong rows; any nonzero count from the database path is a mapping bug. In our case each perturbation mode gave tens to hundreds of wrong rows, against 0 for the plain path. 5) Keep the failing design seeds as fixed regression fixtures. A sweep like this can also expose older bugs, e.g. a duplicated --top argument collapsing generate indices.