Use ClientConfig.node_id as canonical UI node identity

[henrixd7]

Summary

This changes node identity handling in the UI so it no longer relies on the gRPC transport peer as the canonical node key.

Why

The UI currently keys remote nodes off the transport peer. That is not a stable logical identity:

• reconnects can change the peer even for the same daemon
• proxies/tunnels can cause several daemons to arrive from the same loopback peer

In environments like Qubes OS, that means multiple daemon VMs can collapse into a single UI node.

What this changes

• adds node_id to ClientConfig
• daemon populates node_id
• UI uses node_id as the canonical node key when present
• transport peer remains in session metadata for reconnect/cleanup/debugging
• name remains display text
• if node_id is absent, the UI keeps a compatibility fallback for older daemons

Files

• proto/ui.proto
• daemon/ui/notifications.go
• ui/opensnitch/nodes.py
• ui/opensnitch/service.py
• focused UI tests

Notes

• this PR is intentionally limited to the identity model
• it does not include local Fedora/Qubes RPM or build-system changes
• the tracked Python protobuf artifact is updated because ClientConfig changed

Verification

• targeted UI tests for:
  • node_id-based registration
  • reconnect preserving logical identity
  • fallback behavior when node_id is absent

Refs #1577