[Ticket]: listRoles/listPermissions read API for /settings/roles

### Type
Feature

### Summary
We need to expose a read API for RBAC role/permission mappings because the converse-frontends console's IA v3 phase 2 ("the settings area") wants a `/settings/roles` screen and there is currently no procedure that lists roles or the permissions each one carries.

Expected result:
> A cratestack procedure (e.g. `listRoles`) that returns the operator-configured role catalogue — role id/name plus the permission set each grants — read-only, gated at a sensible existing permission (mirroring `listBillingPlans`/`listModelCatalog`'s "read the catalogue you'd need to build a picker" pattern).

### Intent
`/settings/roles` in the console is currently a real, permanent nav row that renders `aria-disabled` with a stated reason, rather than either a fabricated screen or a silently missing one (console-ui skill's "never fabricate" clause). The reason is: role and permission mapping is operator config today, and nothing on the RPC surface can read it back. This ticket unblocks building the real screen.

### Source of truth (links)
https://github.com/ADORSYS-GIS/converse-frontends/issues/368 (IA v3 phase 2 — "the settings area")

### Current Behavior
No `authz.cstack` procedure lists roles or permissions. The console has no way to render `/settings/roles` truthfully, so it ships the nav entry disabled with an explanatory reason instead of a fabricated or empty screen.

### Expected Behavior
A read-only procedure (`listRoles` or equivalent) returns every configured role with its id/name and the permission set it grants, analogous in shape and gating to `listBillingPlans(): BillingPlanInfo[]` / `listModelCatalog(): ModelCatalogEntry[]`.

### Acceptance Criteria
- [ ] Given an authenticated caller with an appropriate read permission, when they call the new procedure, then they receive the full role/permission catalogue.
- [ ] Given a caller without that permission, when they call it, then they receive a clear authorization error.
- [ ] Error cases are handled safely.
- [ ] Existing behavior is not broken.
- [ ] Relevant tests are added or updated.
- [ ] Verification evidence is provided.

### Out of Scope
Writing/editing roles or permissions from the console — this ticket is read-only, matching the console's own role-gating philosophy (roles stay operator config; the console only needs to render them).

### Technical Context
`packages/authz-rpc/schema/authz.cstack` — see `listBillingPlans`/`listModelCatalog` for the established "operator-configured catalogue, read-only" pattern this should follow. Consuming side: `apps/console/src/client/console-chrome.tsx`'s `ROLES_DISABLED_REASON` names this issue; once it lands, the console side replaces the disabled nav row with a real `/settings/roles` screen.

### Risks
None beyond ordinary API-surface growth — read-only, additive.

### Test Plan
Unit tests on the new procedure's authorization gate and its shape; a converse-frontends follow-up wires the console screen and adds its own tests/stories.

### Verification evidence
Filed from the converse-frontends IA v3 phase 2 work (branch `claude/ia-v3-p2`) as a blocking backend gap discovered while building `/settings/roles`. No code change in this repo yet — this ticket tracks the gap itself.

### Human accountable owner
@stephane-segning

### AI Usage Declaration
Drafting the ticket, Understanding code

### Human verification completed
- [ ] I am the accountable owner and accept responsibility for this ticket. (assigned at open time per team convention; owner review pending)