Config file, user service, and a build container that can see bluez

`--config` reads the same directives as the command line, one per line with
the rest of the line as the command, so a unit can carry the kiosk's events
without shell quoting. presence.service is a systemd --user unit that runs it
from ~/.config/presence/config, restarts on failure, and only starts when the
file exists; config.example is the starting point.

The x86_64 release job failed on makepkg's runtime dependency check because
bluez was not in the container. It is now.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

README.md

@@ -73,6 +73,29 @@ kiosk's own peripherals once you know their addresses.
 Commands run through `sh -c` as the user who started `presence`, which in a
 sway config is the session user, so `swaymsg` finds the right socket.
 
+## Config file and user service
+
+The same words, one per line, with the rest of the line as the command and no
+quoting rules. The package ships `/usr/share/doc/presence/config.example`:
+
+```
+rssi -58
+present swaymsg "output * power on"
+absent 600 swaymsg "output * power off"
+```
+
+`presence --config ~/.config/presence/config` reads it; command-line options
+override the file, events from both are used. A `systemd --user` unit is
+installed that runs exactly that, so as the kiosk user:
+
+```
+mkdir -p ~/.config/presence && cp /usr/share/doc/presence/config.example ~/.config/presence/config
+systemctl --user enable --now presence
+```
+
+It restarts on failure and only starts when the config exists. Starting it
+from the sway config with `exec presence ...` works just as well; pick one.
+
 ## Requirements
 
 `bluetoothd` must be running (`systemctl enable --now bluetooth`). BlueZ's