fix(image): drop the gpu_mem settings from config.txt

Nothing in FPP has drawn on the firmware GPU memory split for years. The
comment justifying these still referenced omxplayer, which is long gone --
that comment was the last mention of it in the tree. Video now goes through
GStreamer, and the display, DPI and virtual-matrix buffers all come from the
vc4-KMS CMA pool, which the installer already sizes to 256MB on the overlay
line just above. There is no MMAL/OpenMAX path left to feed.

What the settings were actually doing:

  pi5   256  no effect at all -- the firmware does not implement a GPU
             memory split on this SoC, and vcgencmd reports the key as
             unknown on a running board
  pi4   256  ~180MB carved out of usable RAM, 3.4x the documented maximum
             of 76 for this model, where the 3D block has its own MMU and
             allocates from Linux instead
  pi3   128  ~52MB above the 76 default
  pi02  128  64MB above the default, on a board with only 512MB total
  pi2    64  actually BELOW the 76 default for a 1GB board
  pi1    64  equals the default -- no-op
  pi0    64  equals the default -- no-op

So the entries were a mix of no-ops and waste, with the worst on the two
most memory-constrained cases. Removing them restores the firmware defaults
(64 below 1GB, 76 at 1GB and up) rather than substituting fresh guesses. The
model blocks that held nothing else go with them; the ones that carried real
settings keep them.

Verified on a Pi 5: with the entries gone the board boots clean, CMA is
unchanged at 256MB, and the web UI and daemon come up normally.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: dkulp

SD/FPP_Install.sh

@@ -1153,25 +1153,21 @@ init_uart_clock=16000000
 dtoverlay=miniuart-bt
 
 # Model Specific configuration
-# GPU memory set to 128 to deal with error in omxplayer with hi-def videos
+#
+# No gpu_mem here, deliberately. The firmware GPU split is a legacy setting and
+# nothing in FPP draws on it any more: video goes through GStreamer (the old
+# omxplayer/MMAL path is long gone), and the display, DPI and virtual-matrix
+# buffers all come from the vc4-KMS CMA pool sized above. A Pi 5 ignores
+# gpu_mem outright; on a Pi 4 the 3D block has its own MMU and allocates from
+# Linux instead, where the documented ceiling is 76 -- so the 256 this used to
+# set just carved ~180MB out of usable RAM. Unset lets the firmware pick its
+# own default (64 below 1GB, 76 at 1GB and above), which is what we want.
 [pi5]
-gpu_mem=256
 dtparam=uart0=on
-[pi4]
-gpu_mem=256
-[pi3]
-gpu_mem=128
-[pi0]
-gpu_mem=64
 [pi02]
-gpu_mem=128
-dtparam=audio=off                                                                                                                                                                                                            
-hdmi_force_hotplug=1                                                                                                                                                                                                         
+dtparam=audio=off
+hdmi_force_hotplug=1
 hdmi_drive=2
-[pi1]
-gpu_mem=64
-[pi2]
-gpu_mem=64
 
 [all]