Unify CClient/CServer as a single orchestration layer behind UI and JSON-RPC

[pljones]

Summary

Currently, Client and Server capabilities and states are scattered across UI and other classes rather than "owned" centrally.

This issue proposes refactoring so that CClient and CServer become the single source of truth for all state and actions, with both the Qt UI and the JSON-RPC interface acting as symmetric, parity consumers of that layer - nothing more.

(This came out of discussion on #3660 - and prior discussions - where a small RPC addition (getCurrentDirectory/getDirectories) surfaced duplicated logic between CConnectDlg and CClientRpc that should really live in one place.)

Goals

• Clear separation of concerns between orchestration logic and presentation/control interfaces.
• CClient and CServer as the orchestration core - the single arbiter of all Client/Server capabilities, state, and actions.
• Full parity between UI and JSON-RPC. Anything the UI can do, JSON-RPC can do, and vice versa. No interface-specific logic duplicated across them. This should be sufficient, for example, to let someone write a local JSON-RPC + React (or any other) frontend that fully replaces the Qt UI.
• CSettings / CClientSettings / CServerSettings encapsulated behind CClient and CServer, rather than read or mutated directly by UI or RPC code.

Proposed pattern

Using "current directory" as a worked example:

1. CClient owns the state (e.g. current directory index) and exposes it via a canonical accessor.
2. UI components (e.g. CConnectDlg) emit a signal on user interaction (e.g. "selection changed").
3. CClient handles the signal and updates CClientSettings.
4. CClientSettings emits its own change signal.
5. Both the UI and CClientRpc listen and react independently — UI updates its display, RPC pushes new state to subscribers.

Neither the UI nor RPC owns logic the other doesn't have equal access to; both sit on top of the same CClient-owned state and signals.

Scope of JSON-RPC control

There is no remaining debate on how much should be controllable via JSON-RPC: full parity with the UI is the goal, including actions that affect other clients on a server (e.g. join/leave, mute). Restricting RPC to read-only, or to a subset of UI actions, would defeat the purpose — it would prevent RPC or other future mechanisms from being a viable full replacement for the UI.

Scope of exposure (local control)

Jamulus should continue to expose JSON-RPC only to the host machine itself. However, what the operator of that machine chooses to do with that local API - including running their own server-side bridge to expose a remote UI - is entirely outside Jamulus's domain and not something Jamulus needs to secure against. Jamulus's responsibility ends at the local socket; anything built on top (e.g. a remotely-accessible UI) is the hosting user's own responsibility.

Non-goals / explicitly out of scope for this issue

• Ripping out CLI parsing and Settings persistence on the Server side (raised as a related but separate, larger job).
• The longer-term "Jamulus as a DAW plugin" direction (bridges to Reaper/Audacity, etc.) — interesting, but a much bigger and more speculative rewrite than this issue is scoped for.

Whilst out of scope, it's hoped that the change in architecture will help towards both.

Why now

This is a foundational refactor that unblocks a class of feature requests (e.g. setCurrentDirectory, directory management setters) that keep surfacing in feature PRs and forcing the same "should this be centralized" conversation each time. Doing it once, centrally, avoids repeating this discussion piecemeal across future PRs.

Suggested approach

Incremental, in parallel with existing functionality — migrate one area of state/action at a time (starting with connection/directory handling, per the example above) into CClient/CServer ownership, with the existing UI and RPC code updated to consume it, rather than a big-bang rewrite. Keep the current implementation working throughout.

[pljones]

This could be a good time to find out how "Create sub-issue" works if we do directly address this. However, I'm expecting it to act more as a direction of travel for the time being at least.

[ann0see]

Since it seems like a large undertaking and hard to review, we should have a detailed architecture plan before implementing and then probably small PRs?

[pljones]

Yes. I'm also thinking we need to start with that plan and make it something to be adhered to in the same way as the contributing guidelines, etc (i.e. suitable for AI Agents to digest).