Update Me

Self-service profile edit (jwt) — the caller's own name/phone/email/UI language only.

Declared beside /me (before /{user_id}) per convention. User is GLOBAL, so the self-write via ScopedDep needs no tenant elevation. Privileged fields are not in :class:MeUpdate, so a user can never escalate within this request.

Returns the same envelope GET /users/me does — one path, one answer to "who am I" (:func:_me_response).

Refused inside a support session, locked or unlocked. Editing your own account is a platform act, not part of a tenant visit — the same distinction :func:refuse_credential_ops_in_support_session draws for key issuance, and it is keyed on the session existing at all for the same reason: unlocking authorises a write to this customer's books, never a write to the platform's own identity rows. User is GLOBAL, so no ring filters it and this router gate is the only authorization there is — :func:deny_company_scoped_key below cannot serve, because it keys on the API-key header and an operator inside a session holds a browser session. Left open, the visit's audit trail asserted a confinement to one tenant while the operator rewrote a row belonging to none of them, and the email half is the takeover vector the next paragraph describes. Ring 3 refused the locked half as an ordinary write, with a message about the customer's books that this write is not.

Refused for a company-scoped API key (ZET-176). The absent privileged fields are not the whole story: email IS the account's login identity, so writing it escalates out of band — change the owner's email, ask /auth/request-reset for an OTP at the new address, reset the password, log in. A credential confined to one company would come out the other side holding the owner's full session, is_admin included, and every gate this ticket added would be moot. Same privilege-persistence reasoning as :func:require_session_user on key management, one route over.