T3871: never guess a pending node's hardware when ambiguous

Reported against the previous PCIe/MAC-sorted replacement fill: on a
real, already-provisioned box (hw-id from historical probe-order
rescan, unrelated to any PCIe/MAC sort), a configured node's address
ended up silently applied to a different physical NIC. Deleting one
interface's hw-id (keeping its settings) while a different, unrelated
interface's config was fully removed in the same boot was enough - the
two freed candidates' MAC order didn't match their old name order, so
the deterministic sort swapped them. Once written back by the rescan
helper, the wrong binding became permanent and self-reinforcing on
every later boot.

There's no way to verify, from MAC and PCIe position alone, which of
several unconfigured candidates is genuinely a given node's own
hardware once its hw-id is gone. Restore strict matching: a node only
recovers its hw-id automatically when it's the sole pending node of its
type this boot and exactly one candidate exists - any other count
leaves it pending and reported rather than guessed. A candidate that
isn't matched this way is not otherwise held back - it still gets an
ordinary, settings-free bootstrap name instead of being lost, just
never inherits another node's configuration.

This necessarily changes what a combined "delete one interface fully,
clear a different one's hw-id" reboot can auto-resolve; the accompanying
test-harness change acknowledges that trade-off explicitly.

0 files changed, 0 insertions, 0 deletions