Set the website's design tokens

Merges a flat token patch into the site’s theme, optionally on top of a named preset. Read GET /theme-tokens first for the tokens, their allowed values and the presets. This writes the draft, like every other edit here - nothing a visitor sees changes until POST /releases publishes it. That is the point of tokens living on the website rather than on the organization’s branding: a palette change is previewable, versioned in the release, and revertible. Merges field by field, so setting the heading font leaves the palette alone. Send null for a token to return it to what it inherits - from the organization’s branding, from another token, or from the platform default. That is the only way back once a value has been written; there is no “unset” string. A preset is the exception to that merge: it REPLACES the look rather than adding to it. Every token any preset owns is cleared first, then the chosen preset’s values are written. Otherwise switching from night to editorial would keep night’s whole dark palette underneath and leave the site describing a hybrid nobody chose. Tokens no preset owns - a hand-picked brand colour - are untouched. When preset and tokens are both sent the preset is applied first and the tokens land on top, so “use the editorial look but keep our heading font” is one call. Every problem with a patch is reported at once rather than one at a time. Tokens are validated against the catalog: an unknown key, a value outside a token’s options, a font the site cannot load, or a colour that is not a hex are all refused rather than stored - a colour CSS cannot parse does not fall back, it paints the surface transparent.