pipewire: fix thread-loop lifetime & recursive-lock crashes in the shared context

[ogauthiersat]

Summary

Fixes three related crashes/deadlocks in the shared PipeWire context
(backends/linux/pipewire/context.hpp) that surface when the thread-loop
backend is used from real applications — driving the loop from foreign threads,
reconnecting a broken context, and using several MIDI objects (or MIDI + an
audio filter) on the shared context at once.

All three were found integrating this layer into
ossia score (audio + MIDI sharing one
libremidi::pipewire::context), tested against PipeWire 1.4.2.

Bugs & fixes

1. synchronize() iterated the thread-loop from two threads

For loop_kind::thread, do_sync_locked() called pw_loop_iterate() on the
shared pw_loop from the calling thread while the pw_thread_loop worker was
iterating the same loop. Two threads iterating one pw_loop corrupt its
per-source dispatch bookkeeping (s->priv / s->rmask, with a per-thread stack
ep[]) and double-dispatch the core-socket callback, ending in
pw_protocol_native_connection_flush(conn=0x0) on the worker thread (segfault
at process exit, when teardown floods the socket).

Fix: for the thread loop, issue pw_core_sync and wait on a private
std::condition_variable instead of iterating — the single worker drives the
loop and on_core_done / on_core_error wake the waiter.

2. reconnect() tore the loop down from inside itself

reconnect() wrapped tear_down() + build_connection() in invoke_sync(),
so they ran on the worker thread. But tear_down() stops and destroys that same
loop: pthread_join(self) is a silent no-op and pw_thread_loop_destroy() then
unlocks a loop it is running inside → 'this->recurse > 0' failed in
do_unlock() and the blocking invoke never returns (hang).

Fix: run the tear-down/rebuild/sync on the calling thread, and bail out early if
called from the loop thread.

3. Recursive thread-loop lock misused in invoke_sync() and synchronize()

Two more 'recurse > 0' failures + deadlocks, both stemming from PipeWire's
thread-loop mutex being PTHREAD_MUTEX_RECURSIVE:

• invoke_sync() (used by unsubscribe()) called
  pw_loop_invoke(block=true) without holding the thread-loop lock.
  PipeWire's blocking invoke wraps its wait in the loop control hooks
  (do_unlock before / do_lock after), so it requires the caller to hold the
  lock exactly once. Unlocked, do_unlock underflows the recurse counter and
  the stray do_lock leaves the mutex owned by the wrong thread, deadlocking
  the next pw_thread_loop_stop() join. Fix: hold the lock around the blocking
  invoke.

• synchronize() held the recursive lock across
  pw_thread_loop_timed_wait(); pthread_cond_wait cannot fully release a
  recursively-held mutex, so nested/concurrent syncs starved the worker and
  corrupted the lock. Fix: the private-CV wait never holds the
  loop lock across the wait, and synchronize() now guards is_in_loop_thread()
  (drives iteration directly on the worker rather than waiting on itself).

pw_thread_loop_timed_wait is no longer used and is dropped from the
thread_available gate.

Verification

Standalone reproducers against a live PipeWire 1.4.2 daemon (each reproduced the
failure before the fix, clean after):

• Create/destroy context + repeated synchronize() (was: flush(conn=0x0) at exit).
• reconnect() from the main thread, ×N (was: recurse > 0 + SIGSEGV).
• MIDI-style filter + port + synchronize_node() + port subscriptions, teardown
  (was: recurse > 0 at unsubscribe, then pw_thread_loop_stop deadlock).
• Audio-style filter created/destroyed repeatedly while a MIDI filter +
  subscriptions stay live on the shared context.
• Sync stress (tens of thousands of round-trips), reconnect loops, nested and
  loop-thread synchronize().

Regression tests

Added under examples/backends/ (built when LIBREMIDI_HAS_PIPEWIRE):

• pipewire_context_sync — create/synchronize/destroy cycles + a sustained
  synchronize() loop.
• pipewire_context_reconnect — repeated reconnect() from the calling thread.
• pipewire_context_subscriptions — subscribe/unsubscribe churn, MIDI-style
  filter teardown with live subscriptions, and synchronize() from a subscriber
  callback.

Each skips (exit 0) when no PipeWire daemon is reachable and arms a watchdog so a
lock-corruption regression fails instead of hanging. Against the pre-fix code,
pipewire_context_reconnect and pipewire_context_subscriptions reproduce
'this->recurse > 0' failed + SIGSEGV; all three pass after the fix.

Notes / not addressed here

reconnect() still rebuilds the loop and core, which invalidates pw_filters
that other holders created on the old ones — inherent to PipeWire (a lost core
connection kills all proxies). It's only reachable on a genuine daemon
disconnect. Coordinating dependent filter recreation across a reconnect is left
for a follow-up.

Disclosure

The implementation in this PR was produced with an AI coding
agent (Anthropic's Claude Opus 4.8) using omp.
I directed the work, reviewed every change, and ran the verification
described above; I take responsibility for its correctness and licensing.

[jcelerier]

Heads-up: #229 contains this PR verbatim (authorship preserved) plus #227's format.hpp buffer-param ranges and a reconciliation of the two invoke_sync fixes — merging #226 and #227 independently would auto-merge cleanly but deadlock (double lock on the recursive mutex; the loop-control hooks release exactly one level). Reviewed against pipewire's thread-loop.c/loop.c; validated with ossia score's 28-cell PipeWire round-trip harness on 1.3.0.