docs: add known issue for management bridge MAC change after NetworkManager migration

[tillo]

Problem

After the wicked → NetworkManager migration (Harvester v1.6.x → v1.7.x), the management bridge mgmt-br is no longer protected against MAC address changes.

Under wicked, /etc/wicked/scripts/setup_bond.sh ran a bond post-up hook that pinned mgmt-br's MAC address to the bond MAC. That script still ships in /oem/90_custom.yaml, but it is dead code now that NetworkManager is the active network stack — wicked is inactive, so the hook never runs.

mgmt-br then behaves as a plain Linux bridge and adopts the lowest MAC address among its enslaved ports. Bridge-mode VM networks enslave VM veth interfaces into mgmt-br, so the bridge MAC can change on any VM start/stop/migrate.

This breaks Layer 2 load balancers: MetalLB's L2 ARP responder caches the announce-interface MAC at creation and keeps advertising the stale value. Once the originating veth is removed, that MAC exists on no interface and every affected LoadBalancer IP becomes unreachable — an intermittent, hard-to-diagnose outage where the backing pods are healthy, the IPs are reported as assigned, and ARP still resolves, but to a MAC that black-holes traffic.

Change

Adds Known Issue #6 to the v1.6.x → v1.7.x upgrade page: the failure mode plus a remediation — a NetworkManager dispatcher script that re-pins mgmt-br to the bond MAC on every network event, persisted via an /oem config file so it survives reboots and upgrades. This restores, under NetworkManager, the behaviour the old wicked setup_bond.sh hook provided.

Applied to docs/ and the version-v1.7 / version-v1.8 copies.

Notes

• Observed and remediation verified on Harvester v1.7.1.
• This may also warrant a product-side fix — Harvester could carry the NetworkManager-era equivalent of setup_bond.sh so no manual step is needed. Happy to file a separate harvester/harvester issue for that if maintainers prefer.