SaveShopLanguages

Declaratively replaces the complete set of languages assigned to a shop. The request describes the full desired state - every language contained in it is assigned and every language not contained in it is unassigned. The call is therefore idempotent: repeating it with the same body leaves the shop in the same state, and because the language is addressed by its natural code (ADR-85) rather than by a server-generated surrogate, no clientId or request token is needed to make a retry safe. Exactly one assignment must be marked as the default language, and the list must not be empty - a shop without any language cannot display anything, so clearing all assignments is not an accepted target state on this route. Codes are matched case-insensitively and returned in their canonical lowercase form. Languages that carry no ISO 639-1 code cannot be addressed through this endpoint and are therefore never assigned or returned. Note on the response shape: unlike a command that returns only the minimal necessary data, this one echoes the complete resulting assignment list, matching the declarative-replace example in ADR-57 - it saves the caller a follow-up read to learn the canonical form of the codes it submitted and the resolved language names. The response reuses the list item of the GET on this route, so every entry carries IsAssigned - always true here, because this response describes the assignment set rather than the language catalogue. Concurrency: this write is last-writer-wins. It takes no If-Match header and no row version, so two concurrent calls for the same shop overwrite each other without a conflict being reported - the second call simply wins. That is a deliberate choice for the first release: requiring a precondition later would be a breaking change, so it is called out here rather than left implicit. Unlike the customer group command on this resource family, this route never answers 409 - that sibling reports a business conflict there, not a concurrency one. Side effects: a successful replace also feeds the shop synchronisation queue so the change reaches the connected shop. That feed is not part of the same database transaction as the assignment write - if it fails, the assignments are already persisted while the caller sees an error, and repeating the call is the intended recovery.