Client does not start on macOS: uncaught filesystem_error for /run

Description

Since #5961 was merged (commit 16fc1a9c / merge 3616998b, 2026-08-20), the client no longer starts on macOS. It aborts immediately after printing the version banner:

<I> This is Mumble v1.7.0
libc++abi: terminating due to uncaught exception of type std::__1::__fs::filesystem::filesystem_error: filesystem error: in create_directories: Read-only file system ["/run"]

Mumble::getRuntimeDirectory() in ipcutils/IPCUtils.cpp falls back to /run/user/<uid> whenever XDG_RUNTIME_DIR is unset, and then calls the throwing overload of std::filesystem::create_directories. On macOS XDG_RUNTIME_DIR is never set, /run does not exist and the root filesystem is read-only, so the call throws and nothing catches it.

Before the refactoring, SocketRPC::start() fell back to $HOME/.MumbleSocket in that situation, which is why this only affects master and not 1.6.x.

This is not macOS-specific in principle: any Unix system without /run/user/<uid> (non-systemd setups, some containers, FreeBSD) hits the same code path.

Steps to reproduce

1. Build the client from current master on macOS (cmake .. -DCMAKE_OSX_ARCHITECTURES=arm64 -Dserver=OFF, Qt 6.11).
2. Run Mumble.app/Contents/MacOS/Mumble.
3. The process terminates before the main window appears.

Mumble version

1.7.0 (master, 1ce8d426)

Mumble component

Client

OS

macOS

Reproducible?

Yes

Additional information

The macOS CI job builds the client but never launches it, so this is not caught by CI.

A suitable per-user runtime directory on macOS is the one returned by confstr(_CS_DARWIN_USER_TEMP_DIR, ...) (i.e. the $TMPDIR under /var/folders/...). I have a patch that turns the single hard-coded fallback into a list of candidates and uses only the non-throwing std::error_code overloads, and will open a PR referencing this issue.