[TASK][Backend] Expand branch team workflows with member moves and service assignment

[vugarsafarzada]

Source of Truth

• PRD: https://www.notion.so/3435ef9e213280eaa56ad864787cda02
• Repo: Reziphay/nodejs-app
• Task type: execution-ready backend task for AI/code agents
• Depends on: #7 for stable brand/branch rules and coordination with #9 for service assignment entities
• Blocks: nextjs-app#8 and part of nextjs-app#9

Current Codebase Snapshot

• prisma/schema.prisma already contains Team and TeamMember with invitation lifecycle fields.
• src/routes/v1/team.route.ts already supports team workspace reads, invite, accept, reject, list my invitations, and remove member.
• Notification/feed behavior already assumes team invitations exist, so invitation semantics must not regress.
• Missing PRD rules include moving members between branches, service assignment inside a branch team, and richer owner workspace data.

Goal

Turn the current invitation-focused Team implementation into a branch-operating workspace where the brand owner can manage branch membership and service delivery safely.

In Scope

• Support moving a USO from one branch team to another branch of the same brand.
• Add service assignment and unassignment primitives for accepted team members.
• Represent whether a service is member-owned, branch-owned, or surfaced through the team ecosystem.
• Expand workspace payloads so frontend can render members, pending invites, assignments, and branch context in one read.
• Keep owner-only permission checks strict for invite, move, remove, and assign actions.
• Emit/retain the events needed by the notification feed for invitation and membership state changes.

Suggested Implementation Order

1. Review current invitation/remove flows and preserve their existing contracts where possible.
2. Add the minimum schema needed for assignment and movement auditability.
3. Implement member move logic with validation that the actor owns the brand and the target branch belongs to the same brand.
4. Add assignment/unassignment endpoints that integrate with the service model from #9.
5. Expand workspace read models for frontend consumption.
6. Add tests for owner-only behavior, re-invites, moves, assignment state changes, and invalid cross-brand actions.

Important Constraints For Agents

• Do not break existing invitation acceptance/rejection routes because the frontend notification flow already depends on them.
• Preserve a clear audit trail when a member is moved or an assignment changes.
• Avoid duplicating membership rows if the domain can be modeled safely by transitions on existing records.

Deliverables

• Schema and service updates for team member movement and service assignment.
• New or extended team endpoints.
• Rich workspace response payload(s) for branch/team management screens.
• Tests for permissions and state transitions.

Acceptance Criteria

• A brand owner can move an accepted USO between branches of the same brand.
• A brand owner can assign and unassign services to accepted team members.
• Cross-brand moves or assignments are rejected.
• Existing invite/accept/reject/remove behavior continues to work.
• Workspace responses contain enough data for frontend team management without requiring excessive fan-out calls.

Out of Scope

• Payroll, scheduling, or staff performance analytics.
• Real-time collaboration beyond the domain events/notifications already needed here.