[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)

Start in packages/authz-rpc/schema/authz.cstack and read listBillingPlans and listModelCatalog for the established read-only catalogue pattern and permission gating. Add unit coverage for the new procedure's authorization gate and response shape, then verify that authorized callers receive the configured role and permission catalogue while unauthorized callers receive a clear error.

由索引模型根据 Issue 内容生成。