[Ticket]: Expose the configured API-key expiry ceiling over RPC

## Type

Cross-team dependency (backend / schema)

## Summary

We need the operator-configured API-key expiry ceiling exposed on the RPC surface, because the console's new create-key form currently hardcodes a client-side maximum derived from the *default* value in a schema comment — the same class of guess that produced the `billing_plan: 'standard'` 400.

Expected result:
> The console reads the real `api_key_expiry` ceiling for the deployment it is talking to, instead of assuming 90 days.

## Intent

`packages/authz-rpc/schema/authz.cstack:329` documents the mechanism plainly: `createApiKey` clamps `expiresAt` against an **operator-configured `ApiKeyExpiry` ceiling (config `api_key_expiry`, default 90 days)**. The word that matters is *operator-configured* — 90 days is the default, not the contract.

Nothing on the RPC surface exposes the configured value, so https://github.com/ADORSYS-GIS/converse-frontends/pull/342 ships `MAX_KEY_EXPIRY_DAYS = 89` (the documented default minus a one-day clock-skew margin) as an explicitly-disclosed client-side safety choice. That is honest and it is the best available option today, but it is still the console guessing a value the server owns. On any deployment configured below 89 days, the form offers expiries the backend will reject, and the user meets a server error after filling in the form.

This is precisely the gap `listBillingPlans` was added to close for the *plan* field of the same procedure — its own schema doc says it exists so "a caller building a `createApiKey` UI can build a real selector instead of hardcoding plan ids client-side". `CreateApiKeyInput` has four fields; two of them are server-owned catalogue values, and only one of those is currently readable.

## Source of truth (links)

- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/packages/authz-rpc/schema/authz.cstack (see the `expiresAt` note, ~line 329, and `listBillingPlans`, ~line 572)
- https://github.com/ADORSYS-GIS/converse-frontends/pull/342 (where the constant is introduced and disclosed)
- https://github.com/ADORSYS-GIS/converse-frontends/issues/317 (the billing-plan precedent this mirrors)

## Current Behavior

`CreateApiKeyInput.expiresAt` is required. The console offers 7 / 30 / 89 days. The 89 is derived from a schema *comment* about a default, not from any value read at runtime. A deployment with `api_key_expiry` set to, say, 30 days will reject the 89-day option with a server-side error after submission.

## Expected Behavior

A read-only procedure (or an added field on an existing config-exposing one) returns the deployment's configured API-key expiry ceiling, gated at the same `apikey:create` permission as `createApiKey` and `listBillingPlans` — anyone who may create a key may read the ceiling that constrains it. The console then derives its expiry options from that value and drops the hardcoded constant.

## Acceptance Criteria

- [ ] The configured `api_key_expiry` ceiling is readable over RPC by a caller holding `apikey:create`.
- [ ] The console's expiry control is derived from it, and `MAX_KEY_EXPIRY_DAYS` is deleted.
- [ ] A deployment configured below the default cannot be offered an expiry it will reject.

## Out of Scope

- Changing the ceiling's default or its clamping behaviour — the server-side clamp is correct and stays.
- The billing-plan half, already solved by `listBillingPlans` (#317).

## Technical Context

Backend: `lightbridge-authz`, config `api_key_expiry` / `ApiKeyExpiry`. Frontend: `packages/ui-web/src/components/create-api-key-dialog/`, `apps/console/src/containers/use-api-keys-screen.ts`.

Note this needs the usual cratestack lockstep — a schema change means a coordinated `packages/authz-rpc` regeneration and pin bump, so it should be batched with any other pending schema work rather than taken alone.

## Human accountable owner

@stephane-segning

## AI Usage Declaration

Drafted by AI from a divergence a sub-agent disclosed while implementing #319; the ceiling's operator-configured nature was verified against the schema before filing.