[Ticket]: API-key PREFIX column is identical for every key

## Type

Bug

## Summary

The API-keys ledger's `PREFIX` column shows **`eyJ0eXAi` for every key**. That is the base64url of `{"typ` — the opening bytes of a JWT header, identical for every token ever minted. The column distinguishes nothing.

Observed live on `https://console.ai.camer.digital/api-keys` with 7 real keys, all showing the same value.

## Intent

A key prefix exists so a human can tell one credential from another at a glance — matching a key in the UI against one in a config file or a log line. A column whose value is the same on every row is worse than absent: it looks like an identifier, so a reader trusts it, and it cannot be used to identify anything.

The console is faithfully rendering `ApiKey.keyPrefix` (`authz.cstack:339`, `String @readonly`) — so this is very likely a **backend population** issue, not a display one, but it needs confirming from that side before anyone changes the console.

## Source of truth (links)

- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/packages/authz-rpc/schema/authz.cstack (`ApiKey.keyPrefix`, ~line 339)
- Observed on the live deployment, account `97de3164-…`, 7 keys.

## Current Behavior

All seven keys render `PREFIX = eyJ0eXAi`. Decoding: `eyJ0eXAi` → `{"typ"`. The stored prefix appears to be the first 8 characters of the serialised JWT, which is invariant across keys because every JWT header starts `{"typ":"JWT"...`.

## Expected Behavior

Either:
- **(a)** `keyPrefix` is populated with something actually distinguishing (a short random identifier minted with the key, the conventional `sk_live_…`-style leading segment, or the key id's leading characters); or
- **(b)** if no distinguishing prefix can exist for this key format, the console drops the column rather than showing a constant.

(a) is the better outcome — the column is genuinely useful when populated — but it is a backend change. (b) is the console-side fallback if the format cannot support it.

## Acceptance Criteria

- [ ] Two different API keys show two different values in `PREFIX`, or the column is gone.
- [ ] Whatever is shown is safe to display — a prefix must not narrow the search space for the secret itself.

## Out of Scope

- The secret-reveal flow (`SecretReveal`), which is a separate, one-time surface and works correctly.

## Technical Context

`packages/ui-web/src/sections/api-keys-ledger/`, `apps/console/src/containers/use-api-keys-screen.ts`. Backend: whatever populates `api_keys.key_prefix` in `lightbridge-authz`.

## Human accountable owner

@stephane-segning

## AI Usage Declaration

Observed during a browser pass over the live deployment; the base64 decoding was checked, not assumed.

Start with packages/ui-web/src/sections/api-keys-ledger/ and apps/console/src/containers/use-api-keys-screen.ts, then trace ApiKey.keyPrefix in packages/authz-rpc/schema/authz.cstack to the backend population of api_keys.key_prefix in lightbridge-authz. Compare prefixes for multiple keys and verify that any displayed value cannot narrow the secret search space. Done means different keys have distinct safe values, or the console no longer shows the column.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.