fix(void): package the fork's sources and runtime helpers, not upstream's

The app template fetched upstream's 0.18.5 archive, carried upstream's
homepage and maintainer, and renamed the launchers and desktop entry in
post_install. The fork's sdist already names them voculinux, so the
template now sources the fork's release asset and installs the names as
they are. The checksum is an explicit pending marker until the fork's
v0.18.5 release exists, which fails closed in xbps-src and never falls
back to the upstream digest.

depends now pulls in pipewire (capture), wtype (direct typing on niri),
wl-clipboard (clipboard), xdotool (X11 and XWayland) and pulseaudio-utils
(pactl), and drops ibus, which cannot inject on niri. Every name is
checked against the Void index.

INSTALL.msg states the niri first run plainly (no permission prompt;
typing goes direct), never points at the portal on niri, and drops the
IBus claim. The container smoke queries the fork's distribution name.

Tests assert the fork sources, the pending-or-pinned checksum, the
runtime helpers, the absence of ibus, and the niri wording.

docs/DISTRO_COMPATIBILITY.md

@@ -198,8 +198,9 @@ sudo xbps-install -Sy python3-pip python3-gobject gtk+3 libayatana-appindicator
 ```
 
 Note: `ydotool` is not packaged for Void, so the ydotool injection
-fallback rung is unavailable there; the app uses IBus, the RemoteDesktop
-portal, `wtype` or `xdotool` instead.
+fallback rung is unavailable there. On niri, text is typed directly through
+`wtype` with no permission prompt. IBus is not used on niri. On GNOME and
+KDE the RemoteDesktop portal is tried first where it is available.
 
 ### Solus
 ```bash