fix: Windows daemon survives session jobs; quieter wrap note; correct mute error

Verified on a Windows 11 VM over WinRM: doctor, SAPI synthesis, Edge,
oto/WASAPI playback, autostart, mute file, wrap exit codes, doctor --probe
and toast mode all work. Three findings fixed:

- The autostarted daemon died with the WinRM shell: Windows session hosts
  (WinRM, SSH, CI runners) put children into a job object that is
  terminated with the session. Spawn now starts the daemon with
  CREATE_BREAKAWAY_FROM_JOB first and falls back to a start without it when
  the job forbids breakaway. Confirmed: the daemon now outlives the WinRM
  shell and `talk daemon stop` still ends it.
- `talk mute` without a daemon printed "daemon call failed (<nil>)": the
  outer err was reported instead of the call's. Now "no daemon (<reason>);
  writing the mute file directly".
- `talk wrap` printed "command did not exit cleanly" for every non-zero
  exit code. The note is now reserved for commands that produced no exit
  code of their own (not found, signal); a plain failure is carried by the
  announcement and the exit code alone.

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

README.md

@@ -113,9 +113,10 @@ one announcement at a time, in the order `now` > `high` > `normal` > `low`
 `7800`, config `[server] port`, env `TALK_PORT`.
 
 **Autostart:** when no daemon runs, `talk say` (and `talk wrap`) start it on
-the first speak command, detached from the terminal, logging to `daemon.log`
-with its PID in `daemon.pid` in the config directory; stderr says "daemon
-started" once. The daemon then keeps running (idle costs next to nothing)
+the first speak command, detached from the terminal (on Windows also broken
+away from the caller's job object, so a WinRM, SSH or CI session does not
+take it down), logging to `daemon.log` with its PID in `daemon.pid` in the
+config directory; stderr says "daemon started" once. The daemon then keeps running (idle costs next to nothing)
 until `talk daemon stop`, logout or reboot. Parallel first calls are
 harmless: whoever loses the port race uses the other one's daemon. If you
 manage the daemon yourself (systemd, launchd, Task Scheduler with `talk