Persist workspace creation and teammate invites

[unworthyzeus]

/claim #1

Summary

• creates a personal workspace for users on sign-in
• adds authenticated workspace APIs for listing/creating workspaces and inviting teammates with workspace roles
• replaces the hardcoded workspace rail with real workspace data, selected workspace persistence, and a create-workspace flow with logo, name, optional teammate invite, and role selection

Testing

• corepack pnpm install --frozen-lockfile
• corepack pnpm --filter inbox-zero-ai lint (passes; existing unrelated warnings remain in CommandK, mail-list, and single-image-dropzone)
• corepack pnpm --filter inbox-zero-ai exec tsc --noEmit
• git -c core.whitespace=cr-at-eol diff --cached --check

I used dummy local environment values for lint/typecheck because the app validates required env vars while loading Next config.

[nagiexplorer88]

I think this still misses two core parts of #1.

First, switching workspaces does not appear to scope the mail data. The PR adds selectedWorkspaceIdAtom and stores it from WorkspaceSidebar, but the selected id is not used to filter the accounts/threads/inbox data or to call workspace-scoped mail APIs. That means a user can switch the rail selection while still seeing the same mail/accounts, so the Slack-style workspace separation is mostly UI state.

Second, the issue explicitly includes team invites by email. The new /api/workspaces/[id]/members route only upserts a membership row with invitedEmail / invitedName; I do not see an email being sent, an invitation token/link being generated, or an accept flow. Without that, invited teammates cannot actually join from an email invite.

[unworthyzeus]

Thanks for the review. I pushed a follow-up in 4ebdbc7 that should cover both missing pieces:

• Workspace switching now scopes the mail/account surface. The selected workspace drives the account switcher and every /api/google/threads request via workspaceId/emailAccountId, and the API validates workspace access before returning threads.
• Email invites now send an actual workspace invite email with an accept link. The accept route binds the invitation to the signed-in user, clears the pending invited email/name fields, and redirects back to the selected workspace.

I also wired workspace email accounts for personal/new workspaces so the scoped inbox has real account data to use. tsc --noEmit still has unrelated pre-existing implicit-any failures elsewhere in the app, but the touched workspace/mail/resend files no longer show type errors when filtered.

[nagiexplorer88]

I think one follow-up still leaves new workspaces without scoped mail data.

apps/web/app/api/workspaces/route.ts creates a workspace with only userId, name, and image. But createWorkspaceForUser only creates the workspace email account from options.email / options.userName. Because the POST route never passes session.user.email or session.user.name, ensureWorkspaceEmailAccount receives email as undefined and returns without creating an emailAccount.

Result: a newly created workspace can be selected, but selectedWorkspace.emailAccounts is empty, the account switcher shows "No accounts", and /api/google/threads is called only with workspaceId and no emailAccountId. That contradicts the follow-up claim that new workspaces have real account data. Passing session.user.email / session.user.name into createWorkspaceForUser, or deriving them inside the helper, should keep the scoped inbox usable for new workspaces.