FPP 10.1.2

FPP 10.1.2 is a bug-fix release for 10.1. The full release notes for FPP 10.1 can
be found at https://github.com/FalconChristmas/fpp/releases/tag/10.1

BeagleBone Black users running 10.1 should upgrade — the 10.1 BBB image
booted the wrong kernel and no PRU-driven cape worked on it.

Fixes

BeagleBone Black: PRU capes dark on the 10.1 image (#2966)

The 10.1 BeagleBone Black image shipped booting the stock distribution kernel
instead of FPP's PRU-patched one, so the PRU could not be started and every
PRU-driven cape stayed dark. Both kernels were present on the device; only the
boot pointer was wrong.

• New images boot the correct kernel, and the image build now fails outright
  rather than shipping one that does not.
• Devices already flashed with 10.1 are repaired by the upgrade itself: it
  repoints the bootloader at the FPP kernel already installed. Nothing is
  downloaded and no package is touched. The kernel it selects is read off the
  device and is only accepted if its modules and device trees are both present.
  A reboot is required afterwards.
• The stock kernel packages are now held back, so an apt upgrade on the device
  cannot re-break the boot pointer either.

BB64 - Differential (V4) receivers garbled on a mixed chain (#2964)

On a cape with a send-only V4 receiver alongside a V5 chain, the V4 receiver's
first port was garbled both idle and playing. Send-only chain heads now stay
quiet through the listen window and take their configuration in the frames where
that is safe, so a V4 receiver no longer mistakes the listen cue for a packet.
V5 chains are unaffected.

Upgrading to a specific version silently did nothing

The Upgrade button on the release-notes dialog built a malformed version
reference, so the version switch never happened — and the upgrade script threw
away the failure and reported "Upgrade complete" regardless. The reference is
now built correctly, and a failed version switch is reported as a failure
instead of being hidden.

Pi 5: serial port no longer costs you two GPIO pins

Enabling the serial port on a Pi 5 also claimed GPIO14 and GPIO15 at boot, and
on current kernels that claim is permanent. A cape with a button or a pixel
string on either pin lost it — and a test button on GPIO15 behaved as though it
were held down (#2965). The serial device is now enabled without grabbing the
header pins, matching every other supported board: the pin is claimed only when
something actually asks for it. Existing installs are migrated automatically.

Cape firmware re-flash confirmed the wrong thing

When upgrading cape firmware from a vendor URL, the confirmation dialog read the
cape and firmware names out of the wrong lines and asked about download progress
messages instead. It now finds them by name, and declines to offer a forced
flash at all if they cannot be read.