feat(azure): add vm_id to KVP telemetry event keys

[peytonr18]

Proposed Commit Message

feat(azure): add vm_id to KVP telemetry event keys

Add VM ID to the KVP (Key-Value Pair) event key format to improve
telemetry tracking and debugging capabilities for Azure/Hyper-V
deployments.

Additional Context

The VM ID is now queried during HyperVKvpReportingHandler initialization and appended to each event key. Changes include:

• Query vm_id during HyperVKvpReportingHandler initialization
• Store vm_id as instance attribute with fallback to zero-guid string
• Update _event_key_format_parts() to include vm_id in key structure
• Update event key format to: CLOUD_INIT|<incarnation>|<event_type>|<event_name>|<uuid>|<vm_id>[|subevent_index]
• Added test_vm_id_fallback_to_zero_guid unit test to verify fallback logic.
• Production test shows vm_id in key, where vm_id is 26bd6c2f-ecc6-4b04-9f79-e500096ee45b:

CLOUD_INIT|1762458786|finish|modules-final|b8398a61-459c-4e35-95fd-c3a099396a02|26bd6c2f-ecc6-4b04-9f79-e500096ee45b{"name":"modules-final","type":"finish","ts":"2025-11-06T19:53:30.941724+00:00","result":"SUCCESS","msg":"running modules for final"}

Merge Type

• [x] Squash merge using "Proposed Commit Message"

[peytonr18]

A request was made outside of this PR to re-order uuid and vm_id to ensure RdAgent can distinguish the key, which is the reason for the change in the most recent commit.

[github-actions[bot]]

Hello! Thank you for this proposed change to cloud-init. This pull request is now marked as stale as it has not seen any activity in 14 days. If no activity occurs within the next 7 days, this pull request will automatically close.

If you are waiting for code review and you are seeing this message, apologies! Please reply, tagging blackboxsw, and he will ensure that someone takes a look soon.

(If the pull request is closed and you would like to continue working on it, please do tag blackboxsw to reopen it.)

[peytonr18]

Per offline discussion, There was concern about pulling the same code in azure.identity.py into the reporter, as well as importing the code from the azure module (which is what was done previously).

The current suggestion is to instead have the datasource set vm_id via azure's get_kvp_handler() method, with the eventual goal of eventually caching the vm_id in a shared location and moving all KVP logic out of the HyperVReportingHandler.