Offboard a team member (disable sign-in)

OFFBOARDS a staff account by flipping its active flag to false, which DISABLES sign-in for that person — the deliberate, auditable way to lock a departed colleague out without deleting their directory row (historic sales and audit trails still reference it). This REVOKES system access, the mirror image of createTeamMember: it is a security-posture change, not an ordinary record edit, so surface an offboarding request to a human and never revoke access autonomously. Unlike updateTeamMember, it takes no body — the path memberId is the whole input, so there is no way to touch any other field, and no risk of the active-defaults-to-true trap that a full-record replace carries. Idempotent: offboarding an already-inactive account is a no-op that returns it unchanged. Reactivation is a separate updateTeamMember with active: true. There is NO delete endpoint — this never removes a row. 404s for an unknown member. PERMISSION TRAP (solya-pos#950): x-required-permissions says pos.team.manage, and that is what the router gate checks — but the use-case behind it additionally asserts the kernel permission config:manage, and the scope-to-kernel table (SCOPE_KERNEL_PERMISSIONS) maps pos.team.manage to NOTHING. A token-authenticated actor holding exactly the documented scope therefore passes the gate and then fails with a bare 403 from inside the use-case. Read a 403 here as a server-side grant gap, not as a malformed request, and do not retry it with a different body.