Sync prompts

Declaratively sync an own brand’s active prompt set.

Makes the brand’s ACTIVE prompts equal prompts (at most 500 rows). Matching is on the text, case- and surrounding-whitespace-insensitive, within the brand (coarser than the lower(text) uniqueness index, so several ACTIVE rows can share a key: the oldest is the match and the rest count as rows the request did not name). Per desired row: an active match with identical countries (and platforms / tags where sent) is unchanged; an active match that differs is updated; a text that exists only INACTIVE reactivates the newest inactive row (reactivated, fields updated) — never a duplicate insert; anything else is created (source: "api"). With deactivate_missing (default true) every active prompt not in the request is deactivated. Each desired row is asserted ACTIVE in the same statement that writes it (a row planned as unchanged is asserted conditionally, so a clean sync still writes nothing), which is what makes a downgrade landing mid-run refuse the row instead of editing a prompt it has already switched off: expect failed / brand_archived for those rows, and reactivated where a row planned as unchanged had been switched off on a still-live brand. NOT ATOMIC: rows are applied one by one, deactivations FIRST (so the slots they free are available to the creates and reactivations that follow), then the desired rows in request order; a row refused by a cap (422 codes), by the archived-brand rule (brand_archived) or by the active-text uniqueness rule is reported as failed with its code and the rest of the request still runs. The LAST statement of a deactivate_missing run re-reads the brand’s active set under a brand-grain lock every writer of a live prompt takes: it switches off anything outside the requested set, and RE-ASSERTS the DESIRED STATE of the rows this call applied — their countries / platforms / tags (each restored row reported reasserted) and the two claims underneath those, that the row still exists and is still ACTIVE. The sync’s per-row writes and that reconciliation are separate transactions, so a concurrent PATCH, DELETE or deactivation landing between them would otherwise leave the 200 describing a state that had been overwritten. A prompt switched off in that window is put back on with its fields, reported reinstated; a prompt DELETED in it is reported failed / not_found and is not re-created (its text was resolved to an id that no longer names anything — re-run the sync and it is created properly). Re-activation is cap-checked like a create, so one the database refuses is one more failed row and the rest of the reconciliation still lands. A refused row is never re-asserted (nothing was applied to it), and a row whose text another writer changed after it was written is reported failed / prompt_changed and deactivated rather than rewritten. So when this endpoint answers 200, every prompt it says it applied is present, active and carrying the requested fields, or named in results as failed. The response is 200 with a per-row results list (request order, then the deactivated, reasserted and reinstated rows), a summary and the organisation’s usage afterwards. dry_run returns the same shape with the planned actions and writes nothing. Duplicate texts within the request are 400 duplicate_prompt_text. Own brands only (400 validation_error with details[].code = "own_brand_only"); an archived brand is 409 brand_archived, an empty sync included.