setRecordingDirectory replies "acknowledged" while silently disabling recording on a bad path

**🤖 AI:** `jamulusserver/setRecordingDirectory` always replies `"acknowledged"`, but a bad path silently disables recording and discards the stored directory — with nothing to roll back to, and if a recording was already running, it ends the WAV mid-session while the jam continues, unannounced.

**Root cause, confirmed on current `main` (`4a43f6f6`).** [`SetRecordingDir`](https://github.com/jamulussoftware/jamulus/blob/4a43f6f6bd49a37b79817a64450346724cba5752/src/recorder/jamcontroller.cpp#L98-L186) tears down the existing recorder thread ([`EndRecorderThread()` + `wait()`](https://github.com/jamulussoftware/jamulus/blob/4a43f6f6bd49a37b79817a64450346724cba5752/src/recorder/jamcontroller.cpp#L106-L107)) before validating the new directory; on failure [`strRecordingDir` is wiped to `""`](https://github.com/jamulussoftware/jamulus/blob/4a43f6f6bd49a37b79817a64450346724cba5752/src/recorder/jamcontroller.cpp#L184). [The RPC handler](https://github.com/jamulussoftware/jamulus/blob/4a43f6f6bd49a37b79817a64450346724cba5752/src/serverrpc.cpp#L342-L352) reports `"acknowledged"` regardless of which branch ran.

**Measured on a headless build (`wt-3861`, 2026-08-12; the cited lines read identical on current `main`).** A parent-is-a-file path and a path beyond `PATH_MAX` both flip `enabled`/`initialised` `True → False` and `recordingDirectory` → `""`, RPC still `"acknowledged"`.

**A recording already in flight stops at the instant the bad call returns.** A growing WAV (950,272 → 975,916 bytes across a good call) sits flat at every checkpoint afterward, while `getClients` keeps reporting the same live connection throughout — the jam itself is untouched, so nobody in the room is told recording just ended.

The identical failure is loud in the GUI — [`GetRecorderErrMsg()`](https://github.com/jamulussoftware/jamulus/blob/4a43f6f6bd49a37b79817a64450346724cba5752/src/serverdlg.cpp#L611-L618) drives a `QMessageBox::warning` — and silent over RPC, which discards the same string. `getRecorderStatus`'s `errorMessage` does carry it, and the method's own doc comment says to re-check — a caller who does so can catch this — but nothing prompts the re-check, and "acknowledged" does not suggest a session recording just silently ended.

---

🤖 *This message was written by AI and reviewed by @mcfnord.*

Commencez par SetRecordingDir dans src/recorder/jamcontroller.cpp et le handler setRecordingDirectory dans src/serverrpc.cpp ; comparez leur chemin d’échec avec GetRecorderErrMsg() dans src/serverdlg.cpp et getRecorderStatus. Reproduisez un chemin invalide et un enregistrement en cours, puis établissez la réponse d’échec RPC attendue et le comportement de l’état de l’enregistreur avant d’identifier la couverture des deux cas.

Rédigé par le modèle d'indexation à partir du texte de l'issue.