Re-onboard a team member (restore sign-in)

RESTORES an offboarded staff account by flipping its active flag back to true, which RE-ENABLES sign-in and makes the member assignable again. It is the exact inverse of deactivateTeamMember, and the reason offboarding is safe to prefer over deletion: an offboard made in error costs a click rather than a lost history. Like the deactivate route it takes no body — the path memberId is the whole input. It restores ONLY assignability and sign-in: it re-grants no role, re-opens no register session and revives no document. Role grants survive an offboard untouched (they live in role_assignments, not the directory row), so a reactivated member returns with the grants they had and nothing more. This GRANTS system access, so surface the request to a human and never restore an account autonomously. Idempotent: reactivating an already-active account is a no-op that returns it unchanged. 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.