API: add headroom to the query language cap to remove the fragile boundary

[johan-bell]

Closes #1811

The non-CMS query language cap sat exactly on the boundary it needed to allow: the app lets a user pick 3 preferred languages (MAX_PREFERRED_LANGUAGES) plus 1 auto-appended display default, and the API cap (QUERY_MAX_LANGUAGES) defaulted to 4 — i.e. 3 + 1, with zero headroom. These constants live in separate packages, coupled only by comments, so any drift (bumping the client cap, or a transient over-cap set before normalization) would push a query to 5 language references and the API would reject it with a 400 — content silently fails to load.

Fix: give the cap one language of headroom — default 5 (3 preferred + 1 default + 1 headroom):

• DEFAULT_MAX_LANGUAGES 4 → 5 (validateQuery.ts)
• query.maxLanguages default 4 → 5 (configuration.ts)
• the controller's ?? 4 fallback now reuses DEFAULT_MAX_LANGUAGES so it can't drift again
• documented the coupling + headroom on both sides (configuration.ts, app globalConfig.ts) and updated api/CLAUDE.md

Raising the cap up is inherently safe — it only ever accepts a previously-rejected query, never rejects a valid one. Raising the client's preferred cap by more than one would still need this bumped to match (now called out in the comments).

Verified: tsc --noEmit clean, lint clean, and validateQuery.spec.ts (48 tests) passes — its assertions reference the constant symbolically, so they exercise the new boundary.

[ivanslabbert]

Check if it will be cleaner to rather send the language cap to clients in the config object sent to connecting clients when connecting to the Socket.io endpoint. In this way the API configured limit will be communicated to clients, avoiding having comment-linked hard coded constants.