feat(poracle): understand PoracleNG's problem+json errors ahead of the v2 move

[hokiepokedad2]

Groundwork for #805. Refs #803.

Corrected. The first version of this PR claimed 5.2.1 breaks error reporting on prod today. That was wrong, and the change is now framed as what it actually is: preparation for the v2 migration.

What is actually true

PoracleNG 5.2.1 answers its new /api/v2 with RFC 9457 application/problem+json and refuses invalid input with 422. Its v1 surface is frozen and unchanged — and v1 is all this application speaks.

Verified against a real 5.2.1 server (a new dual-version instance on dev-01, :3042, alongside the existing 5.1.0 on :3040):

5.2.1  POST /api/tracking/invasion/{id}     -> 400  application/json
       {"message":"Grunt type mandatory","status":"error"}

5.2.1  POST /api/v2/humans/{id}/tracking/pokemon -> 422  application/problem+json
       {"title":"Unprocessable Entity","status":422,"detail":"validation failed",
        "errors":[{"message":"expected integer","location":"body[0].pokemon_id","value":"twenty-five"}]}

Same server, both shapes. So nothing is broken on prod, and nothing in this PR changes behaviour for any user today.

Why do it now anyway

Because of what happens on the first endpoint that moves to v2. CreateAsync matched only BadRequest, so a 422 would fall through to EnsureSuccessStatusCode — the exact path #539 fixed. The HttpRequestException is flattened into 500 "An unexpected error occurred", the user is told the server broke rather than what was wrong with their alarm, and it is logged as a fault. And ExtractMessageAsync looked for message, error or status as strings; problem+json has none of those, since its status is the HTTP code.

Cheaper to get right before the migration than to debug during it.

Approach

Extraction moves to PoracleErrorMessage, which reads both shapes by field name rather than branching on a version or a content type. The names do not collide, so one reader serves both, and a reverse proxy rewriting Content-Type cannot cost a user their error message.

• errors[] is preferred over detail: it names the individual fields refused, which the old format could not do. location arrives as body[0].pokemon_id, so only the trailing segment is shown.
• title is the status phrase, so it answers only when nothing better is present.
• A numeric status is never the message. The old shape put a word there, the new one puts the HTTP code.
• Old-shape precedence is unchanged: message, error, then a string status.
• CreateAsync treats 422 as the caller's problem, so v1 and v2 agree.

One behaviour change beyond that: a body that parses as JSON but carries no explanation now falls back to a plain sentence instead of being echoed. The raw echo is for bodies that are not JSON at all.

Tests

2149 passing. Four carry payloads captured verbatim from the live 5.2.1 instance, including the v1 rejection from that same server — which is the evidence that both shapes have to stay readable.

The two proxy tests were confirmed red against the previous code before the fix went in, and the existing 400 test stayed green throughout.

Left out

PoracleHumanProxy has the same 400-becomes-500 gap on its write paths. It predates 5.2.1 and spans fifteen call sites with differing caller expectations, so it wants its own change.

The per-field mapping onto form controls that #803 describes is a frontend change and is not here. errors[].location is parsed and surfaced, so the data is ready when that lands.

[hokiepokedad2]

Corrected the premise of this PR after standing up a real 5.2.1 server.

I had claimed 5.2.1 breaks error reporting on prod. It does not. PoracleNG's v1 surface is frozen and still answers {"message":..,"status":"error"} at 400 on 5.2.1, and v1 is all this application speaks. The problem+json/422 change is confined to /api/v2. I took that from the release notes and the generated OpenAPI document, both of which describe the v2 surface, and did not check that the distinction mattered.

The code is unchanged and still worth merging — it is a prerequisite for #805 rather than a fix — but the title, body, commit message and changelog entry all said something untrue and now say what I verified. The changelog entry moved from Fixed to Changed and states plainly that nothing changes for users today.

Four tests now carry payloads captured verbatim from the live instance, including the v1 rejection from the same server.

[hokiepokedad2]

Reworked after #814 merged, because it changed what this PR should be.

#814 landed PoracleProblemDetails on the v2 write path — the same reader this branch introduced as PoracleErrorMessage. Same design, same 300-character cap, same "Poracle rejected the alarm." fallback string, arrived at independently. Merging both would have put two implementations of one idea into develop, which is exactly how one of them becomes the one nobody updates.

So PoracleErrorMessage is deleted and the v1 create path now calls PoracleProblemDetails.Describe. That is the real remaining gap: develop's v2 path reads the newer bodies and names the refused field, while v1 — still the path most installs use — was on the old string reader and matched only 400.

Two improvements to the surviving reader, both carried over from this branch's tests:

• Field errors capped at three with a count of the rest. A body refused on a dozen fields rendered a dozen clauses into a snackbar.
• A string status is no longer read as the message. This branch had it in the precedence list and PoracleProblemDetails did not. Its omission is right: v1's status is the word "error", so surfacing it is worse than the fallback. I dropped that test rather than carrying it, since it asserted something undesirable.

The seventeen cases moved onto Describe, including the four captured verbatim from the live 5.2.1 server. PoracleProblemDetails stays internal; the tests reach it via InternalsVisibleTo, matching what the API project already does.

Backend 2345 passing.