Keep parent node identity out of Proxmox child aliases (#2561)

Guests and storage copy their node's NodeIdentity, NodeName and
NodeAliases into ProxmoxData so search and filters agree after a node
rename. canonicalAliases then listed those values as aliases of the
child itself, so every guest answered to the node's alert resource ID
(for example homelab-minipc). The workloads table matches alerts against
canonical aliases, so a single node temperature or memory alert painted
every guest on that node yellow and showed up in each guest's Needs
Attention panel. The shared alias also made the node's own alias lookup
ambiguous in the registry index.

Only the node resource now lists its node identity as canonical aliases.
Children keep the inherited fields in ProxmoxData, which is what search,
storage and backup consumers already read.

docs/release-control/v6/internal/subsystems/unified-resources.md

@@ -684,7 +684,11 @@ but registry IDs, merge keys, parent links, metrics targets, source-native
 guest IDs, external URLs, discovery targets, and actions must not. Children
 such as VMs, containers, and storage inherit the parent's presentation and
 native aliases so Overview, search, API/websocket/mobile, storage, backups,
-and filters agree. A linked agent may enrich the canonical node but cannot
+and filters agree. That inheritance stays in the child's `ProxmoxData`: only
+the node itself lists its node identity, native name, and native-name aliases
+as canonical aliases, because a child carrying them would answer to the node's
+alert resource ID and every guest would show each node alert as its own.
+A linked agent may enrich the canonical node but cannot
 replace a configured override with its hostname; same-name cluster identity
 remains provider scoped even after a native rename.
 Physical-disk resources own cross-source disk identity. When Proxmox inventory