machines/stellio: backport mt7530 .get_stats64 atomic-context fix

The MT7531 on the Flint 2 is MDIO-attached and shares the SoC MDIO bus
with the 2.5G WAN PHY. On 6.18.49 mt7530_get_stats64 takes the MDIO
mutex under the RCU read lock that /proc/net/dev readers hold; when the
WAN PHY is renegotiating (PPPoE flap) the mutex is contended, the read
sleeps in atomic context and the box oopses:

  BUG: scheduling while atomic: zerotier-one/1748/0x00000002
  mt7530_get_stats64 -> dsa_user_get_stats64 -> dev_seq_show
  Unable to handle kernel paging request at 0000afa547cef5f0

Vendor upstream 07d99587396024932e02474c3a5bede71d108454 (mainline
2026-05-04, absent from linux-6.18.y). Applies to v6.18.49 with one
fuzz-1 hunk (6.18 still exports mt7530_switch_ops).

machines/stellio/configuration.nix

@@ -54,6 +54,20 @@
     };
     systemd.coredump.enable = false;
 
+    # Upstream 07d9958739 (mainline 2026-05, not in linux-6.18.y). The MT7531
+    # switch on the Flint 2 hangs off MDIO, and mt7530_get_stats64 took the
+    # MDIO mutex under the RCU read lock that /proc/net/dev holds, so any
+    # stats reader (zerotier-one, node exporter, `ip -s link`) that raced a
+    # PHY access oopsed the box: "BUG: scheduling while atomic" ->
+    # "Unable to handle kernel paging request" on 2026-09-20 09:02 UTC.
+    # Drop once boot.kernelPackages moves to a kernel that carries it.
+    boot.kernelPatches = [
+      {
+        name = "mt7530-get-stats64-atomic";
+        patch = ./mt7530-get-stats64-atomic.patch;
+      }
+    ];
+
     # nixpkgs' services.blocky check runs the aarch64 blocky in a
     # system.checks derivation, which an x86_64 builder without binfmt cannot
     # execute (`--max-jobs 0` -> Exec format error). Validate the same YAML