feat: add organization domain foundation

docs/TASKS/organizations/002-organization-membership-permissions.md

@@ -36,6 +36,40 @@ Users have global accounts. A user can have rights in multiple organizations and
 - External collaborators must not become organization members automatically.
 - Keep permission names explicit; avoid magic strings where local patterns provide constants.
 
+## Permission Model
+
+Use explicit constants in the Organizations module rather than raw strings in handlers.
+
+Initial organization permissions:
+
+- `ManageOrganizationSettings`
+- `ManageOrganizationMembers`
+- `CreateWorkspaces`
+- `ManageWorkspaces`
+- `ManageBilling`
+- `ManageConnectors`
+- `AccessOwnedWorkspaces`
+
+Initial organization roles should map to permissions in code:
+
+- `Owner`: all organization permissions.
+- `Admin`: organization settings, organization members, workspace creation, workspace administration, connector management, and owned workspace access. Billing is not included unless explicitly assigned.
+- `BillingManager`: billing and owned workspace access.
+- `ConnectorManager`: connector management and owned workspace access.
+- `Member`: owned workspace access only.
+
+Workspace-specific permissions may be overridden at the workspace level after inherited organization access is resolved. Billing and connector permissions must never be granted from workspace-level overrides.
+
+Direct workspace members who are not organization members should be labeled `External Collaborator` in workspace membership responses. Organization members with inherited or direct workspace access should be labeled `Organization Member`.
+
+## Implementation Notes
+
+- Add an `OrganizationMembership` persistence model with `OrganizationId`, `UserId`, role/permission data, and `CreatedAt`.
+- Prefer a small Organizations access service for organization access checks and inherited workspace permission calculation instead of adding ad hoc queries to every handler.
+- Update JWT claims only if a task proves claims are needed; permission checks can query current database state first.
+- Preserve existing global Identity roles while introducing organization-scoped roles. Do not reuse global `manager`, `client`, or `provider` roles as organization roles.
+- Add unit tests for role-to-permission mapping and handler/integration tests for access rejection where existing test infrastructure supports it.
+
 ## Likely Files
 
 - `backend/src/Socialize.Api/Modules/Organizations/**`
@@ -46,12 +80,12 @@ Users have global accounts. A user can have rights in multiple organizations and
 
 ## Done When
 
-- [ ] Organization memberships are persisted.
-- [ ] Organization roles/permissions include billing manager.
-- [ ] Organization-level access can grant inherited access to owned workspaces.
-- [ ] Direct workspace-only external collaborators remain supported.
-- [ ] Workspace-level overrides apply to workspace-specific permissions.
-- [ ] Billing and connector permissions cannot be granted through workspace overrides.
+- [x] Organization memberships are persisted.
+- [x] Organization roles/permissions include billing manager.
+- [x] Organization-level access can grant inherited access to owned workspaces.
+- [x] Direct workspace-only external collaborators remain supported.
+- [x] Workspace-level overrides apply to workspace-specific permissions.
+- [x] Billing and connector permissions cannot be granted through workspace overrides.
 - [ ] Backend tests cover inherited, direct, external collaborator, and override access paths.
 
 ## Validation Commands