firefox-fourier: ship RK3399 HW-decode default prefs (closes #8)

Three prefs that gate the patched VAAPI / V4L2-request code path are
'false' upstream and need to be 'true' for the libva-v4l2-request
backend to actually engage on RK3399 / panfrost EGL:

  widget.dmabuf.force-enabled
  media.hardware-video-decoding.force-enabled
  media.ffvpx-hw.enabled

Without them, Gecko's DMA-BUF probe silently fails (panfrost EGL
doesn't trip the right detection), the (Intel-tuned) HW-vs-SW cost
heuristic picks SW, and the FFvpx PDM never selects its HW-capable
variant for VP8/VP9. Net result: fresh profiles SW-decode despite the
0001..0004 unlock patches being applied.

Shipped as a vendor-default file at:
  /usr/lib/firefox-fourier/browser/defaults/preferences/rockchip-fourier-defaults.js

Lower precedence than user.js / about:config — power users debugging
HW decode can still flip them off without touching the package.

pkgrel 1 -> 2.

Closes: #8

arch/firefox-fourier/rockchip-fourier-defaults.js

@@ -0,0 +1,19 @@
+// firefox-fourier — RK3399 V4L2-stateless HW-decode default prefs.
+//
+// The patch series (0001..0004) builds the VAAPI / V4L2-request routing
+// path through libavcodec, but the resulting code path is gated by three
+// other prefs that are 'false' upstream because the relevant probes don't
+// fire on panfrost EGL or trip the Intel-tuned cost heuristic. Without
+// these, firefox-fourier silently SW-decodes on a fresh profile despite
+// having all the unlock patches applied.
+//
+// Filed via marfrit/marfrit-packages#8 — see that issue for MOZ_LOG
+// evidence on fresnel (Pinebook Pro / RK3399).
+//
+// These are *vendor* defaults: lower precedence than user.js and
+// about:config user prefs. Power users who want to disable HW decode for
+// debugging can flip them in user prefs without touching this file.
+
+pref("widget.dmabuf.force-enabled",                  true);
+pref("media.hardware-video-decoding.force-enabled",  true);
+pref("media.ffvpx-hw.enabled",                       true);