split: betoniarka (radio operator) colocated with liquidsoap; musician goes Discord-only

Permissions post-mortem that motivated this: the musician wrote radio
playlists AS ROOT onto a ROOT-OWNED network share which liquidsoap then
read AS USER 'radio' - chown fails on such shares by design (root squash /
uid mapping), so the radio came up and died on the playlists. The fix is
structural: the playlist WRITER now lives in the same container as the
READER, as the same user, on a local volume. No shared partition, no
chown, no uid mapping.

New: conjurer_betoniarka/betoniarka.py - runs inside the radio container
(started by the entrypoint as user 'radio', port 5005):
- library scan -> all_playlist/hit playlists with LOCAL container paths
  (start + every 24h + authenticated GET /rescan)
- bot-facing radio API moved from the musician: /add_to_priority,
  /create_priority_playlist, /request_radio_file, /clear_pr_pls,
  plus GET /ping (health) and /stream (web page)
- radio_log/persistence tailer forwarding play events to the bot's
  /prepped_tracks with the shared API key (bot-unreachable = logged, not fatal)

Musician: pure Discord music player now - keeps /mp3, /update_mp3,
/get_music and the file-share endpoints; all radio playlist writing, radio
paths/env and the tailer removed.

Bot: new CONJURER_RADIO_SERVICE (defaults to CONJURER_FILE_SERVICE so
un-split deployments keep working); radio_commands targets it; separate
'radio' health-gate group on betoniarka /ping (musician group now covers
music_commands + file_search_commands only).

Docker: betoniarka baked into the radio image (python3 + flask/waitress/
requests from Debian debs), port 5005 exposed, entrypoint starts it via
setpriv as 'radio'; data-volume chown is now best-effort with a loud
warning (keep the volume local); docs get the post-mortem + wiring.

Verified: py_compile everything; functional stub tests - rescan writes
local-path playlists, wyszukaj scores and appends to priority, auth
401/ok, tailer forward carries the API key.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/deployment/DOCKER_PROXMOX.md

@@ -270,7 +270,48 @@ created empty and a silent emergency-fallback mp3 is generated if the
 
 Wire-up: listeners tune to `http://RADIO_VM_IP:8000/mp3-stream`; the bot
 points at `CONJURER_RADIO_HARBOR=http://RADIO_VM_IP:54321` (harbor `/skip`
-lives in the script itself).
+lives in the script itself) and `CONJURER_RADIO_SERVICE=http://RADIO_VM_IP:5005`
+(the betoniarka API below).
+
+### 3f. Betoniarka - the radio operator (and why the split)
+
+**Permissions post-mortem.** The pre-split layout had three actors fighting
+over the same files: the musician wrote radio playlists **as root**, the
+radio expected them **as user `radio`**, and both met on a **root-owned
+network share** where `chown` fails by design (root squash / uid mapping).
+Every component worked; the combination could not.
+
+**The fix is structural**: the process that *writes* the radio playlists now
+lives in the same container as the process that *watches* them, running as
+the same `radio` user on a **local** volume. No network share, no chown, no
+uid mapping - the class of problem is gone, not patched.
+
+`conjurer_betoniarka/betoniarka.py` runs inside the radio container
+(started by the entrypoint as user `radio`, port **5005**) and owns:
+- the library scan → `all_playlist.playlist` / `hit.playlist` (local paths,
+  the same ones Liquidsoap resolves), on start + every 24h + `GET /rescan`
+- the bot-facing radio API: `/add_to_priority`, `/create_priority_playlist`,
+  `/request_radio_file`, `/clear_pr_pls` (+ `GET /ping` for health gating,
+  `/stream` for the web page)
+- tailing `radio_log.log`/`persistence.log` and forwarding play events to
+  the bot's `/prepped_tracks` (with the shared API key)
+
+The **musician** is now a pure Discord music player: `/mp3`, `/update_mp3`,
+`/get_music` and the file-share endpoints. It no longer writes any radio
+files and needs no shared partition with the radio VM. The music library
+can still be replicated/mounted on both VMs (read-only on the radio side is
+fine) - playlists reference the *radio VM's local* paths, generated locally.
+
+Bot wiring after the split (env on the bot):
+```
+CONJURER_FILE_SERVICE=http://MUSICIAN_VM_IP:5000   # Discord music
+CONJURER_RADIO_SERVICE=http://RADIO_VM_IP:5005     # betoniarka (radio cmds)
+CONJURER_RADIO_HARBOR=http://RADIO_VM_IP:54321     # liquidsoap /skip
+```
+`CONJURER_RADIO_SERVICE` defaults to `CONJURER_FILE_SERVICE`, so an
+un-split deployment keeps working unchanged. The bot health-gates
+`radio_commands` on betoniarka's `/ping` (separate from the musician group,
+which now covers only `music_commands` + `file_search_commands`).
 
 **Privileges:** Liquidsoap refuses to run as root (`init: security exit`),
 so the main process runs as the dedicated **`radio`** user (member of