Inconsistent error-body shape on malformed vs absent request fields

A minor error-response consistency gap, noted by two reviewers of the naked-revoke rework (each explicitly said it does not rise to a finding — filing so it isn't lost).

Several server endpoints deserialize a required JSON request body and hand-craft a machine-readable `{"error": ...}` body for domain validation failures (e.g. an absent required field). But a body that is *present but malformed* (wrong JSON type for a field, bad base64, etc.) is rejected earlier, during axum's `Json` extraction, which returns a plain-text 4xx — a different, non-`{"error"}` shape. So a client sees inconsistent error-body shapes for two request-parse failures that are otherwise the same class (fail-closed 4xx, no panic or leak either way — this is purely a response-shape inconsistency, not a security issue).

Fix (whichever fits the codebase): install a uniform `JsonRejection` → `{"error": ...}` mapping (an axum error handler / a custom `Json` extractor), or parse the body as raw `serde_json::Value` and do all field validation in the handler so every parse/validation failure returns the same `{"error"}` shape. Low priority; improves API consistency for clients that parse the error body.

Start by locating the server endpoints that deserialize required JSON bodies and use axum's Json extraction. Trace how domain validation errors are shaped versus malformed-body rejections, then review the existing API error tests or add coverage for both cases. Done means malformed and absent-field failures consistently return a machine-readable {"error": ...} 4xx body.

Written by the indexing model from the issue text.