fix(organizations): disable personal account for new SSO signups

[RSO]

Problem

Signing up through SSO created an account with personal_account_disabled=false when it should be true.

The feature that disables the personal account for accounts created specifically to join an org was only ever implemented for the invitation flow (#4447, acceptOrganizationInvite). The SSO JIT provisioning path (processSSOUserLogin → createOrUpdateUser → addSsoUserToOrganization) never touched the flag, so brand-new SSO accounts kept the schema default of false.

Fix

Mirror the invite-flow behavior for SSO, atomically within the membership-insert transaction:

• addSsoUserToOrganization now accepts an optional { isNewUser }. When the membership is actually inserted and the account is brand-new, it sets personal_account_disabled: true in the same transaction.
• sso.ts passes isNewUser: res.isNew (from createOrUpdateUser).
• Existing users who authenticate through SSO keep their current value, matching the invite semantics ("account created because of the org").

The disabling is gated on added && isNewUser. A brand-new user can't have a removal tombstone (so added is always true here), but gating on added keeps the flag from being flipped for a non-member if the tombstone guard ever short-circuits, matching how the invite flow only disables within a successful-insert path.

Tests

• Added two cases in organizations.test.ts: new SSO user → personal_account_disabled=true; existing SSO user → stays false.
• Updated sso.test.ts call-args assertion for the new { isNewUser: true } argument.
• Typecheck passes; targeted SSO and personal-account suites pass; formatted.

Note

This only affects accounts created going forward. Accounts already provisioned via SSO with false need a manual correction (e.g. the admin toggle) if desired.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

Reviewed the SSO JIT-provisioning change that disables personal_account_disabled for brand-new SSO accounts; the flag update is atomic within the membership transaction, isNew semantics from createOrUpdateUser correctly exclude existing/auto-linked users, and behavior mirrors the invite flow (acceptOrganizationInvite) — high confidence, no security, correctness, or performance issues found in the changed lines.

Files Reviewed (4 files)

• apps/web/src/lib/organizations/organizations.ts
• apps/web/src/lib/organizations/organizations.test.ts
• apps/web/src/lib/user/sso.ts
• apps/web/src/lib/user/sso.test.ts

Verification Notes

• addSsoUserToOrganization has exactly one production caller (apps/web/src/lib/user/sso.ts:84), so the new optional options argument introduces no unhandled call sites or breaking change.
• res.isNew is true only on genuine user-record creation (apps/web/src/lib/user/index.ts:746); sign-in and auto-link paths return false, so existing users retain their current flag value.
• The kilocode_users update runs inside the same transaction as the membership insert and is gated on added, so no flag flip occurs for non-members (e.g. removal-tombstone short-circuit).
• Read-only review: no code executed and no tests run in this environment.

---

_{Reviewed by claude-opus-5 · Input: 58 · Output: 7.5K · Cached: 1.3M}

_{Review guidance: REVIEW.md from base branch main}