feat(core): pair every registry code with the status and prose it answers

§5's `application/problem+json` envelope needs more than a code: RFC 7807 wants
a status, a title, a detail and a documentation link, and the Zig daemon keeps
all of it in `errors/error_entries.zig` beside the codes. This ports that table.

It lives in afd_core rather than the HTTP crate because the status a code
answers with is a property OF THE CODE. `docs/AUTH.md` rests on UZ-AUTH-022
being a 403 — re-authenticating cannot help, so a 401 would send a client round
a loop that never terminates — and on UZ-AUTH-004 being a 503, which the runner
client classifies as transport loss rather than an auth rejection. Two callers
picking a status per call site is how those drift apart.

`docs_uri` is derived rather than stored, so a code cannot link to another
code's anchor. An unregistered code degrades to a 500 "Unknown error" exactly as
`error_registry.lookup` does, and a test proves no declared code reaches it.

The pinning test earned itself immediately: it caught two entries invented
wholesale. `UZ-APIKEY-004` lives in `error_entries_runtime.zig` — the entries
are split across TWO files for the 350-line cap — and a search of only the
first "proved" it had no entry. `UZ-INTERNAL-003` is declared as
`e(S_UZ_INTERNAL_003, …, S_TITLE_REQUEST_FAILED, …)`, naming constants rather
than literals, so a literal search missed it too. The test now reads both files
and resolves `const NAME = "value"` before matching, which is the general fix;
special-casing the two would have left the next one to be found the same way.

The entries are struct literals rather than `e()`/`eu()` helpers. The helpers
mirrored Zig's constructors nicely and were only ever const-evaluated, so
llvm-cov reported 26 lines of never-called body — the same measurement shape
`const_starts_with` hit in afd_auth, and not worth public API to paper over.

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