[fix] Preserve bridged MAC addresses across VM upgrades

[Fail-Safe]

Replacing a persistent VM disk during an upgrade currently changes its bridged MAC because the launcher ties the address to the disk file's device, inode, and creation time. Existing DHCP reservations then stop matching even though the user is upgrading the same VM.

This change stores a versioned identity with a stable MAC alongside the VM's data. Existing MAC records migrate without changing the address, including when the disk has already been replaced. App updates, disk replacement, resizing, resets, and moves of the complete VM data folder retain the address. Damaged or unsupported records fail visibly instead of silently generating another address.

The bridged Networking sheet displays the MAC and provides Copy MAC and Generate new MAC…. Regeneration shows the proposed address and explains the DHCP-reservation impact before confirmation. It is disabled while the VM is open, and the final write checks the launcher's workspace lock plus the expected current MAC to reject concurrent launches or stale dialogs. Migration and regeneration retain the previous record for recovery.

A newly created workspace receives a fresh identity; copying the complete data folder deliberately preserves its identity. The documentation tells users to generate a new MAC before running such a copy as a separate VM. This PR does not introduce an import/duplicate workflow or change NAT and ephemeral-VM address behavior.

Validation:

• Full make test on macOS with the Xcode toolchain, including Swift, guest, networking, launcher, storage, and build/cache tests.
• New identity tests cover legacy migration, replacement disks, moved data folders, explicit regeneration, stale requests, the actual launcher lock, malformed/unsafe records, and concurrent identity creation. The existing networking regression test now requires disk replacement to retain the MAC.
• Full native app assembly with the published v0.4.0 guest/runtime payload; strict code-signature verification and all 21 packaged Mach-O compatibility checks. This is app-source validation using release payloads, not a fresh guest/QEMU source build.
• Built-app UI checks against a disposable workspace: existing MAC display, cancellation without a record change, confirmed regeneration with matching on-disk/new displayed MAC and backup, and disabled regeneration while the workspace lock is held. No live DHCP reservation or daily-driver VM was changed for these checks.