Several VMware reconciliation safety/correctness fixes validated against v1.8.1

[jamespage001]

Hi,

Firstly, thank you for netbox-sync. We've recently moved an older deployment
onto v1.8.1 and have now put it into regular use against an existing VMware /
NetBox environment.

During the work we hit a number of edge cases in controlled LIVE
reconciliation. We investigated these rather than simply working around them,
and have made several local changes against v1.8.1 which I think may be useful
upstream.

Before opening a collection of PRs, I wanted to check how you would prefer
these to be contributed.

The main findings are:

1. DELETE paths can still be reached with pruning disabled

   During a controlled LIVE run, some child-object / unused-object paths could
   still reach DELETE behaviour despite pruning being disabled.

   Our NetBox API account deliberately has no delete permission, so the
   operations were rejected with HTTP 403. A subsequent NetBox Change Log
   audit confirmed zero successful deletes.

   We have locally hardened this so pruning-disabled operation does not send
   those DELETE requests.

2. Weak VM matching can conflict with VMware UUID identity

   We encountered separate VMs sharing MAC/IP-like identity while having
   different VMware UUIDs.

   We added a guard so weak MAC/IP candidates must be compatible with the
   VMware UUID, plus protection against two source UUIDs claiming the same
   NetBox VM in a single run.

3. Same-VID VLAN matching can select an incompatible VLAN

   Our NetBox contains multiple VLAN objects with the same VID but different
   site/group scope.

   We encountered a case where the incorrect candidate was selected. Our
   current fix evaluates scope, rejects explicitly incompatible candidates and
   refuses to guess when equally valid candidates remain.

4. Ambiguous physical-interface matching

   We found a case where insufficient physical-interface identity could lead
   to an arbitrary candidate being selected.

   Our local behaviour now avoids arbitrary matching when the relationship
   cannot be established safely.

5. Stable NetBox API pagination

   We added explicit stable ordering (ordering=id) for paginated NetBox
   queries to avoid page traversal depending on undefined API ordering.

We also have a couple of changes which may be more policy-dependent, such as
retaining existing NetBox VM IP relationships when VMware does not currently
observe them. I would probably discuss those separately rather than assuming
our preferred behaviour should become the upstream default.

The environment we've validated against is roughly:

• netbox-sync v1.8.1
• NetBox 4.2.x
• VMware vCenter source
• ~579 VMs in NetBox
• IMPORTANT : existing/historical NetBox data rather than a greenfield import

For the first failed LIVE run we preserved the logs and audited the resulting
NetBox Change Log, then validated the fixes through dry runs, targeted
canaries and a subsequent successful controlled LIVE run.

I have the changes separated/documented locally and can produce focused PRs
rather than submitting our entire internal patch set.

Would you prefer:

• one issue per behaviour followed by a focused PR;
• PRs directly for the smaller fixes;
• or another structure?

Happy to provide sanitized logs/reproduction details where useful.

Thanks again for the project.