fix(rpi4): drop fkms-3d, mainline does full KMS without an overlay

With the mainline kernel from the previous commit, the device-tree overlay
step fails outright:

  Applying overlay rpi4-cma-overlay
  Applying overlay rpi4-vc4-fkms-v3d-overlay
  libfdt.FdtException: pylibfdt error -1: FDT_ERR_NOTFOUND

nixos-hardware's fkms-3d applies two overlays that patch nodes present in
the Raspberry Pi VENDOR kernel's DTBs and absent from mainline's. Predicted
when the kernel changed; this is it arriving.

It is also the wrong thing to want. "fkms" is FIRMWARE KMS, the older
arrangement where the VideoCore firmware owns the display and Linux drives
it at arm's length. Mainline does full KMS, and mainline's own
bcm2711-rpi-4-b.dtb already describes the hardware: it carries
brcm,bcm2711-vc5 and brcm,2711-v3d nodes, confirmed by decompiling the DTB
with dtc. The vc4 and v3d drivers bind to those directly, no overlay
involved.

So the overlay was not providing capability, it was translating for a
kernel we no longer use.

hardware.deviceTree.overlays is now empty, so there is nothing left for the
overlay builder to fail on. Verified by evaluating the config.

No replacement needed for videoDrivers either. fkms-3d used to set it as a
side effect, but the shared configuration.nix already declares modesetting,
which is correct for full KMS and is what the x86 machines use. Setting it
again here just produced ["modesetting" "modesetting"].

Still unproven on hardware: whether X comes up on vc4 rather than falling
back to a framebuffer. That is the next thing to read out of
/var/log/X.0.log once the machine boots, and it is now a minutes-long
iteration rather than a kernel compile per attempt.

deploy/nixos/hardware/raspberry-pi-4.nix

@@ -59,11 +59,27 @@
   # the kernel falls back to the device tree's stdout-path, i.e. this UART.
   boot.kernelParams = [ "console=tty0" ];
 
-  # Kiosk display: vc4/v3d kernel modesetting via the firmware KMS overlay.
+  # Kiosk display: mainline full KMS, NOT nixos-hardware's fkms-3d.
-  # This is the Pi 4's equivalent of the Pi 5's default KMS path — it also
+  #
-  # sets services.xserver.videoDrivers to modesetting (fbdev fallback), so we
+  # fkms-3d applies the rpi4-cma-overlay and rpi4-vc4-fkms-v3d-overlay device
-  # don't set that here. Electron renders through it as on the UP Board.
+  # tree overlays. Those target nodes that exist in the Raspberry Pi VENDOR
-  hardware.raspberry-pi."4".fkms-3d.enable = true;
+  # kernel's DTBs and not in mainline's, so with the mainline kernel above the
+  # overlay step fails outright:
+  #
+  #   Applying overlay rpi4-vc4-fkms-v3d-overlay
+  #   libfdt.FdtException: pylibfdt error -1: FDT_ERR_NOTFOUND
+  #
+  # It is also unnecessary. "fkms" is FIRMWARE KMS, the older route where the
+  # VideoCore firmware owns the display and Linux drives it at arm's length.
+  # Mainline does full KMS instead, and mainline's own bcm2711-rpi-4-b.dtb
+  # already describes the hardware — it carries brcm,bcm2711-vc5 and
+  # brcm,2711-v3d nodes, checked with dtc. The vc4 and v3d drivers bind to
+  # those directly with no overlay involved.
+  #
+  # fkms-3d used to set services.xserver.videoDrivers as a side effect. Nothing
+  # needs to replace it: the shared configuration.nix already declares
+  # modesetting, which is the correct driver for full KMS and what the x86
+  # machines use. Setting it again here only produced a duplicate entry.
 
   hardware.enableRedistributableFirmware = true;