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

Dieses Issue hat noch niemand übernommen.

## 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.

Beginne damit, CConnectDlg und CClientRpc rund um das Beispiel für das aktuelle Verzeichnis nachzuverfolgen, und untersuche dann, wie CClient, CServer, CClientSettings und CServerSettings derzeit den Zustand besitzen oder verfügbar machen. Migriere schrittweise jeweils einen Zustand oder eine Aktion, während die bestehende Funktionalität erhalten bleibt; als abgeschlossen gilt es, wenn die UI und JSON-RPC dieselbe Orchestrierungsschicht mit vollständiger Parität und ohne duplizierte Logik zur Zustandsverwaltung verwenden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.