Re-enable a disabled member.

Requires users:delete, NOT users:create. Enabling and disabling are two halves of the same lifecycle action and share one permission, so a key that can invite members cannot bring a disabled one back — that takes the same grant as offboarding. Clearing disabled_at restores sign-in across every organization the user belongs to, but only a member of the calling organization can be enabled.

POST /users/:id/enable — flip disabled_at back to NULL so the user can sign in again. Reuses users:delete permission because enable is the inverse of the same lifecycle action.

Atomic: the UPDATE filters on disabled_at IS NOT NULL so two concurrent enables can’t both report success (only the first will return a row; the second sees no row and falls back to a follow-up SELECT to distinguish “user is not disabled” (409) from “user does not exist” (404).