Deactivates a user (soft delete). The user will no longer appear in listings but their data is preserved.

Refuses with 409 when the deactivation would leave the company with no ACTIVE user able to reach access management (SELF_LOCKOUT_MODULES) — see user_roles_db.deactivate_user_with_lockout_guard, which owns that invariant inside the write transaction.

Offboarding (#906). The same transaction also takes the user out of every team and moves their OPEN leads (active/unaccepted/inactive):

• ?transfer_leads_to=<id> — all of them to one active colleague;
• ?transfer_mode=round_robin — each lead to the next eligible member of its OWN team, the way live attribution deals them out;
• neither, and the user owns open leads — 409, naming the count. The admin has to decide who inherits the pipeline; without this the leads stayed pointed at an account that can no longer log in (66 such leads accumulated on one prod user before this ticket).

The parameters are Annotated[...] rather than = Query(...) defaults on purpose: the security suites call this handler DIRECTLY with positional args, and a bare Query(None) default would arrive as a Query object instead of None.