Feature Request: Allow workspace owner to invite members directly as admin

Self Checks

• I have searched for existing issues, including closed ones.
• I confirm that I am using English to submit this report.
• I have not modified this template and filled in all required fields.

1. Is this request related to a problem you're experiencing? Tell us your story.

When a workspace owner wants to invite someone as an admin, the current flow requires two separate steps:

1. workspace.users.invite — which always provisions the member with WorkspaceRole.MEMBER (role is hard-coded in inviteWorkspaceMemberByEmail inside apps/backend/src/services/workspace/index.ts).
2. workspace.users.grant — a second call to elevate the role to admin.

The invite step also calls sendInviteEmail() synchronously with no error isolation. If the email service is unavailable or times out, the entire invite operation fails with an unhandled exception, and the user sees "An unexpected network error occurred." This means the two-step admin-invite flow is unreliable even when both API calls are correctly issued.

2. What is your proposed solution?

• Single-step admin invite: extend workspace.users.invite (and the underlying inviteWorkspaceMemberByEmail service) to accept an optional role parameter ('member' | 'admin'). When role: 'admin' is supplied by a workspace owner, provisionWorkspaceInvite should write that role directly instead of always defaulting to MEMBER.
• Email error isolation: wrap sendInviteEmail() in a try/catch (or move it to an async MQ job) so that an email-delivery failure does not roll back the DB invite transaction or surface as a network error to the end user.

3. Additional context

Relevant code paths:

• apps/backend/src/services/workspace/index.ts — inviteWorkspaceMemberByEmail (role hard-coded to WorkspaceRole.MEMBER, sendInviteEmail not isolated)
• apps/backend/src/services/workspace/invite_write.ts — provisionWorkspaceInvite (accepts role param, already correct; just needs the caller to pass the right value)
• apps/backend/src/engine/interaction/handlers/syncless_handler.ts — WORKSPACE_USERS_INVITE case (does not forward a role to the service)
• apps/backend/src/services/llm/syncless_tools.ts — workspace.users.invite tool descriptor (no role field in argsSchemaSummary)

Start with inviteWorkspaceMemberByEmail in apps/backend/src/services/workspace/index.ts, then trace provisionWorkspaceInvite in invite_write.ts and the WORKSPACE_USERS_INVITE handler in syncless_handler.ts. Check the workspace.users.invite descriptor in syncless_tools.ts for the exposed arguments. Done means owner-supplied admin roles reach provisioning directly and email-delivery failures no longer fail the invite operation.