feat(api): the problem+json envelope, and one clippy lint that cannot be met

§5 Dimension 5.4. Every client-visible refusal goes out through
`ProblemResponse`: status, title, docs link and end-user sentence all come from
the code's registry entry, so a code answers the same status everywhere it is
raised. A caller supplies only the detail and the request id.

Three shape changes from `problem_response.zig`, each with a reason:

The body is a `serde_json::Map`, not a `#[derive(Serialize)]` struct. Deriving
pulls `serde_derive`, a syn-2 proc macro, into a graph otherwise on syn 3 — the
same trade the workspace manifest already records for `zeroize_derive`. Since
`serde_json` carries `preserve_order`, insertion order IS wire order, so the
field sequence is stated in one place rather than inferred from a struct
definition elsewhere.

There is no serialisation-failure arm. `Value::to_string` writes to a String
and cannot fail. The Zig writer needs its `catch` because `std.json.fmt`
targets a fixed response buffer that can run out; reproducing it here would be
a branch nothing can reach — dead code wearing a safety jacket, which is what
§1 removed from `Mac256::compute` for the same reason.

`hint` stays off the wire. It is operator-facing remediation advice, and on a
response it would be handed to anyone who can provoke an error. The Zig
envelope has never carried it; a test now walks every registered code and
fails if its hint text appears anywhere in the rendered body.

Separately: `clippy::multiple_crate_versions` is allowed at workspace level,
with the two chains named. syn 2 arrives via url, idna, icu and yoke-derive,
and url comes from redis, reqwest and sqlx independently; syn 3 via
serde_derive and thiserror-impl. The only remedy would be to drop a datastore.
The lint reads the whole workspace resolve and attaches its diagnostic to
whichever crate is compiling, so which member goes red is an artefact of build
order — afd_api failed it with a graph containing no syn 2 at all. This is not
an amnesty on duplicates we control, and the note says so.

afd_api 100% (388/388), 16 tests.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>