Ask RTKit directly for the speaker tuning's realtime priority (#12958)

The tuning host loaded module-rt with default arguments, so it asked for
realtime through xdg-desktop-portal. A portal started before rtkit was
installed reports a realtime budget of zero. module-rt applies that as a
hard RLIMIT_RTTIME of 0, RTKit still makes the data thread SCHED_RR, and
the kernel kills the host with SIGKILL as soon as audio plays; systemd
restarts it every two seconds and the speakers stay silent until the next
login.

Set rtportal.enabled = false, as the stock pipewire.conf does. The host is
a user service in the same session as the PipeWire daemon and has no
reason to go through the portal.

The host config is only copied by `omarchy-audio-tuning on`, so a
migration replaces an installed copy that is still Omarchy's own with the
old setting, and restarts the host if it runs. It does not call `on`,
which would overwrite a tuning graph another tool wrote under the same
name.

Co-authored-by: Michael de By <contact@michaeldeby.nl>

default/audio/filter-chain-host.conf

@@ -23,9 +23,12 @@ context.spa-libs = {
 }
 
 context.modules = [
-    # Boost the audio thread priority.
+    # Boost the audio thread priority. Ask RTKit directly, as pipewire.conf
+    # does: a portal started before rtkit existed reports a realtime budget of
+    # zero, which becomes a hard RLIMIT_RTTIME of 0 while RTKit still makes the
+    # data thread realtime, and the kernel then kills the host once audio plays.
     { name = libpipewire-module-rt
-        args = { }
+        args = { rtportal.enabled = false }
         flags = [ ifexists nofail ]
     }