fix(evpn): surface cross-class mis-stamped managed netdevs; harden VRF/L3VXLAN validation

[lance0]

Summary

Follow-up to #577. Fixes the one real finding from review plus deferred-lifecycle validation hardening. Status/validation only — no change to compute_managed_netdev_ops or any reap gate (reap stays class-exact).

• Observability regression fix (ADR-0091 Decision 6). The unconfigured/orphan managed-netdev status scan filtered each link to stamps of the class matching its kind, so a link carrying a rustbgpd ownership stamp of the wrong class for its kind (e.g. a bridge-kind link with a rustbgpd:vxlan:… altname) was silently dropped from status — on the prior code it surfaced as owned-unsafe. Restored an all-class fallback so any rustbgpd-stamped link still surfaces (owned-unsafe), never hidden. The fallback never double-emits, and a vxlan-kind link still reports exactly one row.
• Accurate owned-unsafe reasons. Reworded across all four classes to cover wrong-class / multiple-stamp / stamp-name-mismatch instead of implying simple non-ownership.
• Validation hardening (matters when the deferred VRF/L3VXLAN lifecycle lands). Reject reserved VRF table_ids (252–255), a VRF table_id colliding with a [[fib_tables]] table_id, and an L3VXLAN VNI (L3VNI) colliding with a fixed-VNI VXLAN VNI (L2VNI). Operator-provisioned vrf=/bridge= references are intentionally NOT hard-validated (legitimate; fail-closed at runtime).

Testing

• cargo test -p rustbgpd-evpn-linux managed_netdev_status (cross-class mis-stamp surfaced; vxlan-kind emits exactly one; correctly-stamped orphan still orphaned)
• cargo test -p rustbgpd config::tests::managed_netdevs (reserved-table-id, vrf/fib_tables collision, l3vxlan/vxlan VNI collision, valid multi-class loads)
• cargo clippy --workspace --all-targets -- -D warnings, cargo fmt --all -- --check
• pre-push hook: fmt, clippy, test, doc