[Ticket]: refine adapter reads error.payload, RPC client sets error.body

## Type

Bug

## Summary

`@cratestack/refine`'s `toRefineError` reads `error.payload`, but the RPC client's `CratestackRpcError` carries its decoded server error under `error.body`. Any mutation routed through a refine hook therefore surfaces a **degraded** error message instead of the server's real validation text.

Expected result:
> A server-side validation failure reads the same whether the call went through a refine hook or the RPC client directly.

## Intent

Found while implementing #303. The project-creation mutation was deliberately routed through `client.projects.create()` rather than refine's `useCreate` **specifically to avoid this** — matching the pattern `use-api-keys-screen.ts` already uses. That workaround is fine locally, but it means the codebase now has two mutation idioms for the same job, and the reason is a library-shape mismatch rather than a design choice.

This matters beyond cosmetics: the whole point of #319's typed-error work and #323's `notificationProvider` is that a user sees *why* something failed. A degraded message defeats both.

## Source of truth (links)

- https://github.com/ADORSYS-GIS/converse-frontends/pull/350 (where it was found and worked around)
- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/packages/authz-rpc/src/runtime.ts (`CratestackRpcError`, `error.body`)
- https://github.com/ADORSYS-GIS/converse-frontends/blob/main/packages/hooks/src/api-error.ts (documents `error.status` / `error.body.message`, never an Axios-style `error.response`)

## Current Behavior

`CratestackRpcError` puts the HTTP status and the server's decoded error body on the instance — `error.status`, `error.body.message`. `toRefineError` looks for `error.payload`, a REST-client field this client never sets, so it falls through to a generic message.

## Expected Behavior

Either the cratestack refine adapter reads `body` (with `payload` kept as a fallback for REST callers), or this repo supplies its own error normaliser to the data provider so refine hooks and direct calls agree. The first is the better fix — it belongs upstream, next to the client that defines the error shape.

## Acceptance Criteria

- [ ] A `400` from a mutation issued via a refine hook surfaces the same message as the same call issued directly.
- [ ] Covered by a test asserting the server's message text, not just that *an* error occurred.
- [ ] Once fixed, the direct-call workarounds in `use-manage-screen.ts` and `use-api-keys-screen.ts` can be reconsidered — one idiom, not two.

## Out of Scope

- Rewriting either call site now; the workaround is correct and shipped.

## Technical Context

Upstream: `@cratestack/refine`'s `toRefineError`. Local: `apps/console/src/client/console-providers.tsx` (data provider wiring), `use-manage-screen.ts`, `use-api-keys-screen.ts`.

This is cratestack-side, so it carries the usual lockstep constraint — a fix means a version bump held in step with the backend pin.

## Human accountable owner

@stephane-segning

## AI Usage Declaration

Found by a sub-agent while implementing #303; the error-shape mismatch is recorded from the workaround it chose and the reason it gave.