`10-azure-unmanaged-sriov.rules`: `ATTR{flags}` (IFF_SLAVE) match can race hv_netvsc VF bonding, silently leaving VF managed

### Summary
`udev/10-azure-unmanaged-sriov.rules` marks Azure SR-IOV VF interfaces (`mana`, `mlx4_core`, `mlx5_core`) as unmanaged by checking `ATTR{flags}=="0x?[89ABCDEF]??"` (the kernel `IFF_SLAVE` bit). On at least one Rocky Linux 9.8 VM with a `mana` VF, this bit was not yet set when udev evaluated the `add` event for the interface, so the match failed and none of `AZURE_UNMANAGED_SRIOV`, `ID_NET_MANAGED_BY`, or `NM_UNMANAGED` were set. NetworkManager then treated the VF as a normal interface, auto-created a default DHCP profile for it, and (because the VF shares the synthetic interface's MAC) received the same DHCP lease as `eth0`, resulting in a duplicate IP on two interfaces.

### Environment
- Rocky Linux 9.8, kernel `5.14.0-687.39.1.el9_8.x86_64`, systemd/udev 252
- Azure VM size: `Standard_D8ls_v5`
- VF driver: `mana`
- NetworkManager-managed networking (systemd-networkd not in use)

### Root cause
`hv_netvsc` sets `IFF_SLAVE` on the VF only *after* VF registration and datapath bonding complete (confirmed via dmesg: `VF slot added` => `VF registering: eth1` => `Data path switched to VF: eth1`). If udev processes the interface's `add` uevent before that kernel-side bonding finishes, `ATTR{flags}` does not yet reflect `IFF_SLAVE`, the rule's match fails, and (since udev does not re-run rules later when the flag subsequently changes) the interface is never retroactively tagged unmanaged.

This is a race, not deterministic per VM/driver, but its downstream visibility differs by VF hardware generation:
- On Mellanox (`mlx5_core`/`mlx4_core`) VFs, an independent DHCP request sent by NetworkManager over the "slave" datapath is not answered by the host fabric, so the interface just hangs in NetworkManager `connecting` state indefinitely which is mostly invisible/harmless.
- On MANA (`mana`) VFs, the same DHCP request currently is answered (same lease as the synthetic interface), producing a duplicate IP which is user-visible and disruptive (VM can become unreachable on boot).

Reproduced live via:
```
udevadm info /sys/class/net/eth1 | grep -E "NM_UNMANAGED|ID_NET_MANAGED_BY|AZURE_UNMANAGED_SRIOV"
# (no output, properties never set)
nmcli -f GENERAL.DEVICE,GENERAL.STATE,GENERAL.CONNECTION device show eth1
# GENERAL.STATE: 100 (connected) <= should be unmanaged
```

### Possible fix
Replace the bonding-state-dependent `ATTR{flags}` (`IFF_SLAVE`) check with the netdevice's link-layer type, `ATTR{type}=="1"` (`ARPHRD_ETHER`), which is fixed at netdevice registration and is not subject to the bonding-completion race:

```diff
-SUBSYSTEM=="net", ACTION!="remove", DRIVERS=="mana|mlx4_core|mlx5_core", ATTR{flags}=="0x?[89ABCDEF]??", ENV{AZURE_UNMANAGED_SRIOV}="1", ENV{ID_NET_MANAGED_BY}="unmanaged", ENV{NM_UNMANAGED}="1"
+SUBSYSTEM=="net", ACTION!="remove", DRIVERS=="mana|mlx4_core|mlx5_core", ATTR{type}=="1", ENV{AZURE_UNMANAGED_SRIOV}="1", ENV{ID_NET_MANAGED_BY}="unmanaged", ENV{NM_UNMANAGED}="1"
```

**Caveat / open question:** I have not been able to validate this against RDMA-capable VM types that expose a Mellanox ConnectX InfiniBand HCA also driven by `mlx5_core` ([[docs](https://learn.microsoft.com/azure/virtual-machines/setup-infiniband)](https://learn.microsoft.com/azure/virtual-machines/setup-infiniband)). Since udev's `DRIVERS==` match walks up the parent device chain, it's possible the existing `mlx5_core` match already applies to that HCA's netdevice today too in which case `ATTR{type}=="1"` should correctly exclude it (InfiniBand netdevices report `ARPHRD_INFINIBAND`, type `32`, not Ethernet), preserving whatever the current (intended) behavior is for those interfaces. But I don't have access to one of those VM sizes to confirm this doesn't change behavior there, so this suggestion should be treated as a starting point rather than a drop-in fix.

Start with udev/10-azure-unmanaged-sriov.rules and inspect the existing ATTR{flags} match alongside the reported udevadm and nmcli checks. Evaluate the proposed ATTR{type} match on Azure Ethernet SR-IOV VFs and an InfiniBand netdevice; done means the relevant VF properties are set reliably while InfiniBand interfaces remain unaffected.

Written by the indexing model from the issue text.