Add @ocom-verification coverage for Staff Role Management

[nnoce14]

Description
We need to expand test coverage for staff role and permissions management functionality (primarily via @ocom/ui-staff-route-user-management, IAM domain entities, application services, and GraphQL/REST handlers). All test suites derive step definitions from shared scenarios in verification-shared.

What needs to be implemented

• New shared Gherkin feature files / scenarios in verification-shared for the core flows.
• Suite-specific step definition implementations (API, UI, E2E) that reuse the shared steps.
• Any necessary extensions to contexts, world.ts, or Cucumber hooks.

Scope (relevant scenarios)

• Role creation, listing, and viewing details
• Role updates (permissions, name, description, etc.)
• Permission enforcement and authorization checks
• Error cases (duplicate roles, insufficient privileges, validation failures)

Acceptance Criteria

verification-shared

• Add 8–12 new shared Gherkin scenarios covering the flows above, written in clear Given/When/Then style following existing patterns.

acceptance-api

• Implement API-specific step definitions and glue code.
• Cover backend behavior, service calls, persistence, and error handling.

acceptance-ui

• Add UI-specific step definitions for staff portal role management screens (login as staff/tech-admin, create/update/assign roles, verify UI state and feedback).

e2e-tests

• End-to-end scenarios that combine UI actions in the staff portal with API verifications.

General

• Follow existing patterns from verification-shared, step-definitions/index.ts, world.ts, and Cucumber lifecycle hooks.
• Some scenarios may already exist — adjust or extend them as part of this task as needed to ensure full coverage.
• Ensure all tests run cleanly with current mocks (OIDC, in-memory Mongo, mock application services).
• Update coverage configuration and aim for strong coverage on the newly exercised domain and UI code.
• Community deletion is out of scope (not implemented yet).