Add orphaned_device_status and orphaned_vm_status config options

[berlikm]

Closes #458

Summary

Adds two new config options to automatically set the NetBox status of orphaned devices and VMs, as discussed in #458.

When a device/VM is orphaned (no longer reported by its source), the status is changed to the configured value (e.g., decommissioning). This enables downstream systems (like Zabbix monitoring via nbxSync) to react to the status change — for example, removing the host from monitoring when the status is decommissioning.

When an orphaned object reappears in a source, the status is restored to active.

Changes

• module/netbox/config.py: Two new config options (orphaned_device_status, orphaned_vm_status), both optional strings
• module/netbox/inventory.py: Status change logic in tag_all_the_things(), guarded by prune_enabled
• settings-example.ini: Documentation for both options

Design: Why the prune_enabled guard

The status change is only applied when prune_enabled is True. This is critical for source failure protection.

When a source (e.g., vCenter) becomes unreachable, netbox-sync.py already disables pruning:

if source.settings.enabled and not source.init_successful:
    prune_enabled = False
    log.warning(f"disabling pruning as source {source.name} is unavailable")

However, the orphaned tagging in tag_all_the_things() still runs regardless — all objects from the unavailable source get the "orphaned" tag. Without the guard, changing the status to decommissioning during a transient source outage would cause downstream systems to remove monitoring for ALL affected devices/VMs — exactly when monitoring is most needed.

The prune_enabled guard ensures:

Scenario	Tag added?	Status changed?	Monitoring impact
Source down (temporary)	Yes (existing behavior)	No (guard blocks)	None — monitoring continues
Source healthy, VM genuinely deleted	Yes	Yes - to decommissioning	Downstream removes host
VM reappears in source	Tag removed	Restored to active	Downstream re-enables

Without this guard, a vCenter outage could silently decommission hundreds of VMs, removing them from monitoring systems at the worst possible moment.

Scope

• Only affects NBDevice and NBVM — other prunable objects (interfaces, IPs, MAC addresses, etc.) do not have a status field
• Config options are optional — if unset, behavior is unchanged (backward compatible)
• Status values are validated by the existing data_model allowed-values list in object_classes.py

Testing

• Config parsing verified: both options parse correctly from YAML
• Regex matching verified: cluster name patterns match correctly
• Guard logic verified via simulation:
  • prune_enabled=True -> status changes to configured value
  • prune_enabled=False (source down) -> status NOT changed, monitoring preserved
• Dict-style status handling verified (NetBox API returns {"value": "...", "label": "..."})
• Un-orphaning restore verified: decommissioning -> active when VM reappears
• decommissioning confirmed as valid status for both NBVM and NBDevice data models

Config example

netbox:
  orphaned_device_status: decommissioning
  orphaned_vm_status: decommissioning

[semx]

Verified: merges onto development, suite green, and the two options are unset by default. One part is not behind them, though: the "restore status to active" block in inventory.py runs for every previously orphaned device or VM that reappears, whether or not orphaned_device_status/orphaned_vm_status is configured. Today such an object keeps whatever status it has (a user may have set planned or offline deliberately); with this change it is forced back to active on the next run. Could you only restore the status when the corresponding option is set, i.e. when it was netbox-sync that changed it? With that the default path stays unchanged and I can take it.