Add @ocom-verification coverage for Member Management

[nnoce14]

Description
Implement BDD scenarios for member lifecycle operations within communities. End users exist outside of any community (tied to their ui-community login account) and a single user account can belong to multiple communities. Admins create a Member record in a specific community, update it, assign/associate an end-user account, and delete it. All suites derive step definitions from shared scenarios in verification-shared.

What needs to be implemented

• Shared Gherkin scenarios in verification-shared.
• Suite-specific step definitions that bind to those shared scenarios.
• Extensions to shared contexts or test data helpers as needed for member-account association flows.

Scope (specifically scoped shared scenarios)

• Creating a Member in a community
• Updating Member details and roles within a community
• Assigning / associating an existing end-user account to a Member
• Listing / filtering community Members (owner/admin perspective)
• Deleting a Member from a community
• Permission and authorization checks for member management actions
• Handling users who belong to multiple communities

Acceptance Criteria

verification-shared

• Add 8–12 new shared Gherkin scenarios focused on the implemented member flows.

acceptance-api

• API-specific step definitions covering creation, updates, account linking, deletion, validation, and authorization.

acceptance-ui

• UI-specific steps for member management screens in the community portal (and staff portal where applicable), including account assignment workflows.

e2e-tests

• Full end-to-end scenarios (e.g., admin creates Member + assigns account via UI → verify state via API).

General

• Align with current community and iam/member domain contexts and aggregates.
• Reuse and extend existing shared utilities, test data factories, and hooks.
• Some scenarios may already exist — adjust or extend them as part of this task as needed to ensure full coverage going forward.
• Out of scope: End-user invitation flows (not fully implemented). Standalone "member invitation" is not in scope.
• Primary focus on already implemented functionality: member creation, updates, account assignment, and deletion.