Say whether this account is a person or a company. Write-once-ish.

Why it is not a settings toggle

The kind decides which public page an account owns: an individual gets a user_profiles row at /u/{handle}, a company gets a companies row at /c/{handle}. Switching therefore means abandoning one published page and building another -- the old handle stays claimed by a row nothing in the new shape reads, links to it keep resolving to a page the account is no longer maintaining, and any roles hanging off a company become orphans of a company the account has stopped being. That is a support conversation, not a radio button, and every automatic resolution of it (delete the old page, migrate the handle, keep both) is a decision this endpoint has no business making on somebody's behalf.

So the rule is: freely, until it has been used

Settable while the account has neither a profile nor a company row, which is the whole of onboarding -- a user can pick "company", change their mind, and pick "individual" as many times as they like before saving anything. The first save of either page fixes it, and after that this returns 409 with a sentence saying why.

Setting it to the value it already holds is always a 200 and writes nothing, including after a page exists. A client that resends its current state on every settings load must not be told it has a conflict with itself, and "confirm what is already true" is not the operation this endpoint is protecting against.

Query cost

The two existence probes only run when the value is actually changing, so the common no-op path costs one plan read and nothing else. Profiles are keyed by user_id; companies are looked up by owner (any_company_for), since a company row's primary key is now id.