feat: add templateId parameter to management user create

[asafshen]

What

Add the templateId parameter to management.user.create, which was missing while invite / inviteBatch already expose it.

Wired through both call forms:

• options object: create('loginId', { email, templateId })
• positional overload: create('loginId', email, ..., templateId)

Backend CreateUserRequest already accepts templateId (proto field 29), so this is purely SDK-side plumbing over an existing wire contract.

Why

create was the only message-capable user function without templateId. update/patch have no such proto field; createTestUser/createBatch send no message so it's a no-op there.

Closes descope/etc#17215

Tests

Added two create tests (options form + positional overload). Full user.test.ts suite green, tsc --noEmit clean.

🤖 Generated with Claude Code

[shuni-bot]

🐕 Review complete — View session on Shuni Portal 🐾

[shuni-bot]

🐕 Suggested Reviewers

The review assignment strategy balances breadth across core implementation and testing files, leveraging contributors with significant overlapping code experience to ensure thorough review of the new templateId integration.

Reviewer	Reason
dorsha	Dorsha has contributed extensively to both the user test and implementation files, providing broad coverage on the code involved in this feature addition.
aviadl	Aviadl has similar commit history on both relevant files and likely understands the SDK-side changes well, making them a strong reviewer for the implementation details.
yosiharan	Yosiharan also has a balanced contribution across the same files, indicating familiarity with the overall codebase and the specific change scope.
itaihanski	Itaihanski's contribution is limited to the user.test.ts file, which is important for reviewing the test coverage of the new feature.

_{Suggested by Shuni based on git history and PR context. Names are not @-mentioned to avoid notifying anyone — request a review from whoever fits best.}

[shuni-bot]

🐕 Shuni's Review

Wires templateId into management.user.create for both the options-object and positional-overload forms, matching the existing invite shape.

No issues found — good bones! The implementation mirrors invite exactly: templateId lands after additionalLoginIds in the positional signature, flows through the object spread for the options form, and both call forms are covered by the new tests. Woof!