Fix Employer Guards RBAC Access

[yajuusan]

No description provided.

[LoopyB]

Thanks for addressing the invalid EMPLOYEE role reference and adding filtering for soft-deleted guards. These changes are aligned with the ticket, but the PR is not ready for approval yet because several required behaviours and evidence items remain incomplete.

Blocking issue: complete RBAC path

The route now allows ROLES.EMPLOYER through authorizeRoles, but it still immediately applies:

authorizePermissions('user:read')

The fallback Employer permissions in rbac.js do not currently include user:read. This means an employer may pass the role check and still receive 403 Insufficient permissions, depending on the Role configuration stored in the database.

The ticket explicitly requires the route and permission middleware to be aligned. Please verify the complete middleware path and make the smallest appropriate change needed for the agreed access policy. Do not redesign the wider RBAC system as part of this PR.

Required testing and evidence

Please add automated regression tests and PR evidence confirming:

• employer receives 200 OK;
• admin receives 200 OK;
• guard receives 403 Forbidden;
• unauthenticated access receives 401 Unauthorized;
• soft-deleted guards are excluded;
• the response remains compatible with the Employer Panel;
• password fields or other unintended sensitive fields are not returned.

The ticket also requires:

• automated test output;
• curl or Swagger evidence for employer, admin and guard;
• an Employer Panel screenshot showing the guard list loading successfully.

For the Employer Panel screenshot, please show the guard-list page successfully populated while authenticated as an employer. Where practical, also include the related browser Network entry showing GET /api/v1/users/guards returning 200.

Additional updates

Please also:

1. Add a PR description summarising the problem, ticket scope, implementation, testing and any limitations.
2. Confirm the intended Product Owner access policy—specifically whether employers may view all active guards or a narrower employer-scoped set.
3. Correct the controller documentation from Admin,Employee to Admin,Employer.
4. Confirm whether inherited User records always contain isDeleted: false. If the field may be absent, consider whether { isDeleted: { $ne: true } } is required to avoid accidentally excluding older active guards.
5. Revert the unrelated trailing-comma formatting change in rbac.js, as repository-wide formatting is being handled separately under Ticket 7.
6. Formally request review through GitHub once the PR description, implementation and evidence are complete.

The existing CI failure appears to be the known repository-wide Prettier baseline issue, while ESLint passes. That inherited formatting failure is not the primary blocker for this PR.

Requesting changes pending complete RBAC alignment, regression tests and Employer Panel verification.