librenms_id_needs_migration misses server-scoped scalar values

[marcinpsk]

Outside-diff CodeRabbit finding on PR #87; the code is develop-owned (multi-server librenms_id introduced pre-stack), so tracking here for a develop fix.

File: netbox_librenms_plugin/import_utils/device_operations.py (VM branch ~L409-413, Device branch ~L452-456)

The librenms_id_needs_migration flag is only set for top-level legacy scalars (42 / "42"):

_vm_cf_id = existing_vm.custom_field_data.get("librenms_id")
if (isinstance(_vm_cf_id, int) and not isinstance(_vm_cf_id, bool)) or (isinstance(_vm_cf_id, str) and _vm_cf_id.isdigit()):
    result["librenms_id_needs_migration"] = True

But _describe_existing_librenms_link() also treats the server-scoped form {server_key: 42} / {server_key: "42"} as a legacy link (it unwraps cf_value.get(server_key) and coerces a scalar entry to host_id). So such records match as legacy-linked rows yet librenms_id_needs_migration stays False, and the migration path is never offered for them.

Fix: unwrap the current server_key entry before the scalar test, in both the VM and Device branches, so server-scoped scalar storage is flagged consistently.

[coderabbitai]

🔗 Related PRs

#1 - feat: devcontainer proxy support, auto-create librenms_id … [merged]
#18 - fix: cables view per-request interface_name_field, LibreNMSAPIMixin wiring, librenms_id normalization [merged]
#23 - fix: code quality, security hardening, and test coverage improvements [merged]
#41 - Pr/librenms-id-multi-server U#245 [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[marcinpsk]

Re-investigated and declining for now — needs a maintainer data-model decision rather than a code fix. The premise (a server-scoped scalar {server_key: 42} is a legacy link to be flagged for migration) holds only where _describe_existing_librenms_link() exists, which is not on develop. On develop {server_key: 42} is the current per-server form (set_librenms_device_id / migrate_legacy_librenms_id both write it), and an explicit passing test (test_json_format_does_not_set_flag) on both develop and the feature stack asserts it needs no migration. So flagging it would contradict existing tests. If the intended canonical form is the nested {server_key: {"id": 42}}, this should be decided + the test updated first.