[Feature]: Add project-level personas to give users a workflow role

### Description

Introduce project-level personas that can be assigned to users independently of their current authorization role (owner, member, admin).

Initial personas could include Product Owner, Business Analyst, Developer, Architect, Tester/QA, Security/Compliance, and Operations/Platform Engineer. The final persona catalog remains to be defined.

A user should be able to have multiple personas within a project, and each persona may be assigned to multiple users. Personas must not grant additional permissions; they describe responsibilities in the delivery workflow.

### Use case

The current permission model does not communicate who is expected to contribute, review, or approve work at a specific stage of the workflow.

Personas would make responsibilities explicit and enable:

- Targeted notifications and review requests, in conjunction with #289. For example, notify architects during application or NFR design, Product Owners during requirement validation, and QA when test scenarios are ready.

- Persona-aware workflow guidance and AI interactions, such as role-specific questions, recommendations, and summaries.
- Better visibility into whether the right stakeholders are represented in a project.
- Future workflow checks for missing required participants or approvals.
- Reporting on participation and review lead times by role.

### Area

Frontend

### Additional context

Suggested initial acceptance criteria:

- Project owners/admins can assign one or more personas to a project member.
- Multiple members can hold the same persona.
- Persona assignments are project-scoped.
- Authorized project members can view persona assignments.
- Existing owner, member, and admin permissions remain unchanged.
- Workflow and notification services can retrieve project members by persona.
- Existing workflows continue to function when no personas have been assigned.

Open questions:

- Should the persona list be fixed, tenant-configurable, or both?
- Can members self-select personas, or must a project admin assign them?
- Do some stages require a persona to review or formally approve an artifact?
- Should users select an active persona when they have multiple assigned roles?

Future consideration: IDP integration

- Personas should initially be managed within the application because no external Identity Provider (IDP) integration or additional user-pool attributes are currently available.
- If IDP integration is introduced later, evaluate optional mapping from identity-provider groups or roles to project personas. This mapping should be configurable and must remain separate from application authorization, so external group membership does not unintentionally grant project access or elevated permissions.

No files or tests are named. First review the existing project-member authorization model and the workflow and notification services, then resolve the open questions about persona catalogs and assignment rules. Done means project-scoped personas can be assigned and viewed without changing permissions, and existing workflows still work when none are assigned.

Written by the indexing model from the issue text.