Linux: server commands always fail with exit 126 because `authorize-commands` never approves `server_cmd`

Summary

On a Linux machine-service install, every server command (server_cmd in vibepollo.conf) fails with exit status 126. The host sends server commands to the session broker as app requests, and the broker only runs commands listed in /etc/vibepollo/session-commands. That manifest is built by sudo vibepollo authorize-commands from apps.json alone, so a server command can never be approved.

Environment

• Vibepollo 2.0.2nightly.d20261030 (commit 45109fb4fb3842462d1d8bd86b06c4c6095d6e9a), native Arch package, machine-service mode
• CachyOS, KDE Plasma Wayland, RTX 5090
• Client: Artemis (Android)

Steps to reproduce

1. In the web UI, add a server command under Configuration → General → Server Commands:
   • Name: Toggle MangoHud
   • Command: /usr/local/bin/mangohud-toggle (root-owned, mode 755, #!/bin/sh)
2. Grant the Artemis client the "Run server commands" permission.
3. Run sudo vibepollo authorize-commands.
4. While streaming, run the command from the Artemis menu: Server Commands → Toggle MangoHud.

Expected: The command runs in the desktop session.

Actual: The command never runs. Each attempt produces this log sequence, both before and after authorize-commands:

vibepollo-machine-host[14232]: Info: Executing server command: Toggle MangoHud
vibepollo-machine-host[14232]: Debug: Parsed target [/usr/local/bin/mangohud-toggle] from command [/usr/local/bin/mangohud-toggle]
vibepollo-machine-host[14232]: Debug: Resolved target [/usr/local/bin/mangohud-toggle] to path ["/usr/local/bin/mangohud-toggle"]
systemd[1]: Started Vibepollo session execution broker connection (PID 147929/UID 952).
systemd[1]: vibepollo-session-exec@153-32776-147929_171104-952.service: Main process exited, code=exited, status=126/n/a
systemd[1]: vibepollo-session-exec@153-32776-147929_171104-952.service: Failed with result 'exit-code'.

The broker's rejected request message does not appear in the journal (the same symptom as vibeshine#322), so the only visible signal is the 126.

Cause

Links point to commit 45109fb:

1. src/stream.cpp#L1904-L1912: IDX_EXEC_SERVER_CMD runs cmd.cmd_val through platf::run_command. On Linux that becomes a broker app request.
2. packaging/linux/vibepollo-session-broker.c#L1412-L1421: An app request is accepted only if command_is_authorized() succeeds. Otherwise the broker returns 126.
3. packaging/linux/vibepollo-session-broker.c#L526-L585: command_is_authorized() matches the exact command string against /etc/vibepollo/session-commands.
4. packaging/linux/vibepollo-machine-host#L221-L241: extract_desktop_authorizations(), called by authorize_commands() at L315, reads only apps.json entries (cmd, detached[], prep-cmd[].do/undo). It never reads server_cmd from vibepollo.conf.

docs/linux/install.md#L179 already notes that global prep commands from vibepollo.conf aren't authorized. Server commands have the same gap but aren't mentioned, so on Linux the "Run server commands" permission currently has no effect.

Suggested fix

Have authorize-commands also collect server_cmd[].cmd (and global_prep_cmd[].do/undo) from vibepollo.conf into the manifest, with an empty working directory. The broker already falls back to the executable's parent directory when the directory is empty (L580-L582). If leaving these out is intentional, it would help to document that and log the rejection reason where users can see it.

Workaround

The broker only matches on the command string, so adding an app in apps.json whose cmd is the identical string, then running sudo vibepollo authorize-commands, should approve the server command too. The cost is an extra, unwanted tile in the client's app list.