Provision a team member

Adds one staff account to the directory. This PROVISIONS a person who can sign in, so only call it on an explicit instruction naming the individual — never to ‘fill in’ a directory. Unlike the customer and product creates, id is REQUIRED and chosen by YOU: nothing is minted server-side. Pick a stable, human-meaningful id (the directory uses user-<firstname>) and check it first with getTeamMember — an id that already exists is a 409 CONFLICT, never an overwrite, so a duplicate is safe but wasted. email must be a valid address (it is the account’s contact), role is a free-text label with no enforced vocabulary (match the labels the directory already uses — a typo silently creates a new role facet), and store is a display label for the store or network the account is scoped to. active defaults to true: the account may sign in the moment this returns. There is NO delete endpoint — the only way back is updateTeamMember with active: false. 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.