fix(dbus): stop forcing the zbus 5 executor onto tokio

zbus features unify across the dependency graph and "tokio" wins over
"async-io": enabling it via rfd, ashpd (secret portal) and ksni's
default features flipped the shared zbus 5 executor to tokio for
accesskit_unix/atspi too — Slint's accessibility backend opens its
D-Bus connection on a plain thread and panicked at startup ("there is
no reactor running, must be called from the context of a Tokio 1.x
runtime"), killing AT-SPI support. Switch every zbus-5 consumer we
control to the async-io backend (rfd "async-std", ashpd "async-io",
ksni default-features off + "async-io"): async-io connections
self-drive from any thread and the futures still await fine inside our
tokio runtime. The zbus 4 group (keyring/secret-service/mpris-server/
qbz-audio) is a separate feature graph and stays on tokio by design.

cc

crates/qbz-media-controls/Cargo.toml

@@ -30,10 +30,14 @@ urlencoding = "2"
 [target.'cfg(target_os = "linux")'.dependencies]
 mpris-server = "0.8"
 async-channel = "2"
-# XDG notification portal (goes over D-Bus). Same crate + tokio runtime the
-# secret portal already pulls in (qbz-credentials uses ashpd 0.13/tokio).
+# XDG notification portal (goes over D-Bus). async-io, NOT tokio: zbus 5's
+# "tokio" feature unifies graph-wide and its executor then requires a tokio
+# reactor on EVERY thread that opens a zbus connection — accesskit_unix/atspi
+# (Slint accessibility) and ksni run theirs on plain threads and panicked at
+# startup ("there is no reactor running"). async-io futures still await fine
+# inside our tokio runtime. Keep in sync with qbz-credentials/Cargo.toml.
 ashpd = { version = "0.13", default-features = false, features = [
-    "tokio",
+    "async-io",
     "notification",
 ] }