JSON-RPC: sendChatText / broadcastChatMessage / setServerName accept unbounded strings

@ann0see ya está trabajando en esto.

Desde el 14/9/2026.

## Describe the bug

`jamulusclient/sendChatText`, `jamulusserver/broadcastChatMessage` and `jamulusserver/setServerName` validate only that their string parameter is a string — no length bound — unlike the sibling chat methods, which reject input above `MAX_LEN_CHAT_TEXT` (1600):

- `jamulusserver/privateChatMessage` — rejects `> MAX_LEN_CHAT_TEXT` (`src/serverrpc.cpp:125`).
- `jamulusserver/setWelcomeMessage` — rejects `> MAX_LEN_CHAT_TEXT` (`src/serverrpc.cpp:325`).

Normal clients cannot produce such input: the GUI chat dialog truncates input at `MAX_LEN_CHAT_TEXT` (`src/chatdlg.cpp:111`). So these three methods deviate from both the peer RPC methods and the GUI path.

### Reachable impact on current `main`

Since #3861 the JSON-RPC transport caps each request line at 16 KiB (`MAX_JSON_RPC_REQUEST_BYTES`, `src/rpcserver.cpp:116`), so the message is transport-bounded. It still exceeds the receive-side limits: `EvaluateChatTextMes` reads at most `MAX_LEN_CHAT_TEXT_PLUS_HTML` (1800) chars (`src/protocol.cpp:1424`) and split reassembly caps at 36 parts, while the sender fragments via `CreateAndSendMessage` with `ceil(len / 550)` parts and no part-count cap (`src/protocol.cpp:590`). Result: a ~16 KiB `broadcastChatMessage` produces a ~27-datagram split burst per connected client that is then silently discarded by every peer. Not memory-unsafe; low severity, but the handlers do not enforce the parameter contract their siblings and the GUI do. An oversized `setServerName` similarly carries into server-list registration messages to directories and clients.

## To Reproduce

1. Run a server: `jamulus -s --nogui --jsonrpcport 22150 --jsonrpcsecretfile ` (secret >= 16 chars), connect one client.
2. Call `jamulusserver/broadcastChatMessage` with `chatMessage` of 10,000 chars. Handler returns ok; peers receive the fragmented message and drop it (receiver bound 1800).
3. Call it with 20,000 chars: transport rejects with `Parse error: Request exceeds maximum size of 16384 bytes`.

Measured against 3.12.5dev (`292506eb`): 15,000-char broadcast accepted with a +416 KB server RSS delta and ~27 split parts per client; 20,000-char rejected by the 16 KiB boundary.

## Expected behavior

`sendChatText`, `broadcastChatMessage` (and `setServerName`) reject input above `MAX_LEN_CHAT_TEXT` with `iErrInvalidParams`, mirroring `privateChatMessage` / `setWelcomeMessage`.

## Version of Jamulus

3.12.5dev (`292506eb`), JSON-RPC enabled.

## Additional context

Formalizes the "String parameters are bounded inconsistently" item of #3916. #3861 bounds the transport; this issue is the remaining handler-level gap.

> 🤖 Used AI: big-pickle, opencode