Build and install the native front-end on musicdolphin

slint-frontend/ in the app repo is a native front-end for the same backend, written
because the React UI is sluggish on this device. This installs it beside the web UI,
never instead of it: the systemd unit is installed but not enabled, so the device still
boots into the kiosk browser and the two can be compared on the same screen.

  systemctl start musikdelfin     # takes over the display
  systemctl stop  musikdelfin     # back to the browser underneath

Unlike pi_musicmouse, which builds the web front-end on the control machine and rsyncs
dist/, this builds on the device. A Rust binary is not portable, and the reason it has
to be built here rather than cross-compiled is worth writing down: these Pis run 32-bit
armhf Raspbian on a 64-bit kernel. `uname -m` says aarch64 and it is misleading;
`dpkg --print-architecture` says armhf and that is the one that matters. Cross-compiling
to armv7-unknown-linux-gnueabihf needs a sysroot, the devices carry no -dev packages to
build one from, and reconstructing one from the Debian archive means owning a glibc skew
risk indefinitely. Spending the device's own CPU once is the smaller liability. The
build is stamped with the commit it came from, so it only runs again when that changes.

The same fact rules out the Skia renderer that the app's own kiosk profile prefers:
rust-skia publishes no prebuilt binaries for armhf. This builds --features desktop -
winit, FemtoVG and the software renderer - and runs as an X client in the existing
session. Worth noting after the fact: the FemtoVG bug that makes Skia the upstream
recommendation (slint-ui/slint#11785, album covers drawn as solid black) was reported on
a Pi 5 with a 64-bit userland and does not reproduce here - covers render correctly.

Three things had to be found by running it rather than reading anything:

The X session belongs to `kiosk`, not root, so the launcher needs that user's cookie and
the unit runs as them. Without it winit fails with "could not initialize backend", which
says nothing about authorization.

winit and glutin dlopen every windowing and GL library they use, so none of them appear
in `ldd` and the binary links happily without them - then aborts on first run with
"Library libxkbcommon-x11.so could not be loaded". The runtime packages are listed
explicitly for that reason.

Raspbian ships no font containing the emoji the design uses as iconography, so the shelf
badges rendered as empty boxes until fonts-noto-color-emoji went in.

First build took 63 minutes: 570 crates, two jobs, nice'd, which bounds peak memory on
musicdolphin's 1.8 GB.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

roles/pi_slint_frontend/README.md

@@ -0,0 +1,44 @@
+# pi_slint_frontend
+
+Builds and installs `slint-frontend/` from the app repo - the native front-end that
+exists because the React UI is sluggish on the kiosk. Installed *alongside* the web UI,
+never instead of it, and the systemd unit is installed but not enabled: the device still
+boots into the kiosk browser.
+
+```sh
+systemctl start musikdelfin     # takes over the screen
+systemctl stop  musikdelfin     # back to the browser underneath
+```
+
+or over SSH, `DISPLAY=:0 /usr/local/bin/musikdelfin`.
+
+## Why this builds on the device
+
+`pi_musicmouse` builds the web front-end on the control machine and rsyncs `dist/`,
+because npm output is portable and npm is not installed on the Pis. A Rust binary is
+not portable, so this role has a harder choice.
+
+The Pis run **32-bit armhf Raspbian on a 64-bit kernel** - `uname -m` says `aarch64`
+and `dpkg --print-architecture` says `armhf`, and the second one is the one that
+matters. The target is `armv7-unknown-linux-gnueabihf`. Cross-compiling to it from the
+control machine needs a sysroot, and the devices carry no `-dev` packages to build one
+out of, so it would have to be reconstructed from the Debian archive - and then kept in
+step with the devices' glibc forever. Spending the device's own CPU once is the smaller
+liability. A rebuild only happens when the commit changes.
+
+The same fact rules out the Skia renderer: rust-skia publishes no prebuilt binaries for
+armhf, so `--features kiosk` would mean compiling Skia from source on a Pi. This role
+builds `--features desktop` - winit, FemtoVG and the software renderer - and runs as an
+X client in the existing session rather than taking over KMS.
+
+`SLINT_BACKEND=winit-software musikdelfin` switches renderer without a rebuild, which
+is the thing to try first if the GPU path misbehaves. The FemtoVG bug that makes
+`kiosk` use Skia upstream (slint-ui/slint#11785) was reported on a Pi 5 with a 64-bit
+userland, so it may well not apply here - but it is worth checking that album covers
+actually appear before drawing conclusions about frame rate.
+
+## First run
+
+Roughly 40 minutes: 570 crates on two cores. Later runs are incremental and usually
+seconds. The build is `nice`d and limited to two jobs, which bounds peak memory on
+musicdolphin's 1.8 GB.