Add an opt-in true LAN bridge with a supported Windows adapter

[btsouth]

Goal

Offer an explicitly selected true LAN bridge so Omarchy can obtain its own LAN identity and accept inbound connections, while keeping NAT and existing LAN port forwarding as the default.

Current facts

• QEMU user networking provides outbound access; Try Omarchy already has local/LAN port forwarding. Those features do not give the guest its own LAN address.
• A true QEMU bridge on Windows needs a compatible virtual network adapter/driver and administrative adapter configuration. The available AMD laptop has active Wi-Fi, disconnected Ethernet and no TAP adapter. Reconfiguring its live network remotely would risk losing access to the test host.
• QEMU's Windows TAP documentation describes a separate driver; do not silently install a driver or change host network bindings.

Acceptance

• Pick and verify a maintained, signed Windows 10/11 compatible L2 adapter path and document Wi-Fi and Ethernet behavior. Require explicit opt-in and elevation for any host adapter changes.
• Preserve stable guest MAC/IP identity, host connectivity, guest-to-host services and existing NAT fallback across boot, sleep, adapter change and failed setup.
• Limit bridge exposure and explain Windows firewall consequences in Settings. Include a reversible disable/cleanup path.
• Test on a disposable Windows network configuration before offering it to users; retain existing port forwarding as the supported solution in the meantime.

Reference: QEMU network emulation.

[btsouth]

September 23 investigation: OpenVPN 2.7 still carries tap-windows6 as its fallback driver, and Microsoft's netsh bridge interface supports Windows 10/11. That gives us a concrete signed-driver candidate and Windows bridge API to evaluate. The available laptop currently has active Wi-Fi, disconnected Ethernet, and no TAP adapter. I am not changing its only network path remotely. The first implementation target should be an opt-in, reversible TAP + wired-Ethernet setup on a disposable host, with explicit administrator approval, stable guest MAC, and verified NAT rollback. Wi-Fi bridging needs separate proof of actual guest LAN connectivity before being offered. Existing NAT/LAN forwarding remains supported.

Sources: https://github.com/OpenVPN/tap-windows6 ; https://openvpn.net/community-docs/community-articles/openvpn-2-7-manual.html ; https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-bridge