Document the style profile endpoints

[lawl-dev]

Adds API reference documentation for the /v3/style_profiles endpoints.

A style profile bundles your other customizations, glossaries, style rule lists, translation memories, example documents and one Spoken Terms collection, behind a single style_profile_id, so one ID stands for a whole translation configuration instead of a list of individual parameters.

Endpoints documented

Method	Path	Scope
GET	/v3/style_profiles	style_profiles:read
GET	/v3/style_profiles/{style_profile_id}	style_profiles:read
POST	/v3/style_profiles	style_profiles:write
PATCH	/v3/style_profiles/{style_profile_id}	style_profiles:write
DELETE	/v3/style_profiles/{style_profile_id}	style_profiles:write

Behavior called out in the descriptions

• The list includes style profiles shared with the account, not only those it owns
• Creation is atomic. If a referenced component ID cannot be used, no profile is created, and the 400 message names the list the bad ID was passed in
• PATCH leaves absent fields unchanged. An empty string clears description and industry, an empty name is a 400, and each component list that is sent replaces that linked set in full
• DELETE returns 204 No Content and only unlinks the bundled glossaries, style rule lists, translation memories, example documents and Spoken Terms collection. They are not deleted
• Only the owner can delete a style profile. One that was shared with the account, and that the account can list and retrieve, returns 404 on delete, the same status as an unknown ID
• spoken_terms_id is singular, not a list. A profile links at most one Spoken Terms collection, applied when the profile is used for speech rather than text. On update, an empty string unlinks it, the same clearing convention description and industry use
• 403 when a spoken_terms_id is sent on a plan without DeepL Voice, and 400 naming the field for a value that is not a valid UUID or that names a collection the account cannot access
• 456 when the account has reached its style profile limit, and 403 when the plan does not include creating style profiles

Changes

• api-reference/openapi.yaml: the two paths, the ManageStyleProfiles tag, and the StyleProfile and StyleProfileId schemas
• api-reference/openapi.json: regenerated with yq -o=json '.' api-reference/openapi.yaml > api-reference/openapi.json
• api-reference/style-profiles/: five endpoint pages
• docs.json: a Style Profiles group under Customize, next to the other customization resources

A question for the reviewer

Field character limits are stated in prose in the field descriptions rather than encoded as maxLength or maximum in the schema, following the OpenAPI conventions in CLAUDE.md.

Worth a second opinion, though: the neighboring customization endpoints do encode their limits in the schema, so the spec now reads two ways depending on which resource you look at. Would you rather these fields match the neighbors, or keep them as they are and treat this as the pattern to move toward? Happy to change it either way, just say which.

Verification

• yq parses the YAML and every new $ref resolves. The regenerated JSON is identical to the previous one apart from the additions
• mint broken-links passes
• mint broken-links --check-anchors reports the same six pre-existing anchors as main and nothing new

Opened as a draft because the endpoints are not released yet.

[lawl-dev]

Closing in favour of #427, the same three commits on a branch in this repository instead of a fork. The Convert YAML specs to JSON workflow checks the branch out of this repo, so it could never resolve this PR's head ref and failed on all four commits here.