fix(gamescope): force the VENDORED wlroots — the binary's portability was luck

Built the patches on a second distro (Nobara 44 / Fedora 44, for the NVIDIA
leg) and the resulting binary would not start on its own host:

    libwlroots-0.19.so: cannot open shared object file

gamescope vendors wlroots as a submodule, but meson prefers a SYSTEM one when
the build host has `wlroots-devel` — and links it shared. Fedora 43 has no such
package, so the `.116` build fell back to the submodule and linked it
statically; Fedora 44's `dnf builddep gamescope` pulls one in, so the same
script produced a binary bound to a library that exists only inside the build
container.

Confirmed rather than assumed: `ldd` on the f43 binary lists no wlroots at all
and its log says `Subproject wlroots finished`, while the f44 log says
`Dependency wlroots-0.19 found` from the system.

The consequence, had Fedora 43 ever shipped `wlroots-devel`: the sysext payload
would have carried a gamescope that cannot start, and it would have surfaced to
users as "HDR just doesn't work" rather than as a build failure. `-Dforce_
fallback_for=libliftoff,vkroots,wlroots` makes every distro produce the same
self-contained binary. All three entries go together — gamescope's own
meson.build hard-errors if the first two are dropped from that list.

Verified after the fix: `ldd` shows no wlroots/liftoff/vkroots and no missing
deps, the binary starts on the Nobara host, and its node offers the same four
formats with the colorimetry props — same result as Bazzite f43.

packaging/gamescope/build-punktfunk-gamescope.sh

@@ -85,9 +85,20 @@ echo "==> configuring"
 #                               package already installs; ours must not collide with it.
 #                               (The layer the nested games load is that one — it is version-
 #                               independent of the compositor binary.)
+#
+# `force_fallback_for` includes **wlroots** on purpose, and it is load-bearing for a binary we
+# SHIP: gamescope vendors a wlroots submodule, but meson prefers a system one when the build host
+# happens to have `wlroots-devel` — and then links it SHARED. The result starts fine on the build
+# host and dies with `libwlroots-0.19.so: cannot open shared object file` anywhere else, which is
+# every machine that installs our package. Fedora 43 has no wlroots-devel so it fell back and
+# linked static by luck; Fedora 44's `dnf builddep gamescope` pulls one in, and the binary built
+# there would not start on the host. Pinning the fallback makes the outcome the same everywhere.
+# (gamescope's own meson.build hard-errors if libliftoff/vkroots are missing from this list, so
+# all three go together.)
 meson setup "$BUILD" "$SRCDIR" \
   --prefix="$PREFIX" \
   --buildtype=release \
+  -Dforce_fallback_for=libliftoff,vkroots,wlroots \
   -Dpipewire=enabled \
   -Denable_tests=false \
   -Denable_openvr_support=false \