v0.4.2 — Shell-escape audio fetch's remote rsync path

Closes bug 3 from the 2026-05-09 bug report.

spectator audio fetch --target HOST --only "stem with spaces" failed because the remote path wasn't shell-escaped before going through SSH to remote rsync. Symptom on a stem like MY-NIMA 1_1 0507:

fetch failed
rsync: link_stat "/home/misha/.co-sa/spectator/audio-out/MY-NIMA" failed: No such file or directory (2)
rsync: link_stat "/home/misha/1_1" failed: No such file or directory (2)
rsync: change_dir "/home/misha//0507" failed: No such file or directory (2)

Real-world hit because macOS meeting recordings often have spaces in basenames (zoom default "YYYY-MM-DD HH.MM Meeting Name.mp3"). Same hazard with parens, brackets, $, backticks — anything the remote shell interprets.

Fix: src/audio.py:fetch() now wraps the remote path with shlex.quote() before joining onto the host: prefix. The remote shell sees one argument, rsync forwards it intact.

Tests: 57/57 (was 55, +2). One feeds a stem combining spaces / parens / brackets / $ / backticks (real-world torture) and verifies shlex.split round-trips the rendered rsync argv to a single token. One pins that the no-host (local-only) branch does NOT add quoting (would create a literal-quote-character filename).

Workaround on older versions

If you can't upgrade right now, plain rsync with the inner-quoting trick works:

rsync -avh --progress \
    'host:".test/audio-out/My Recording/"' \
    /tmp/dest/