Report a rejected parameter as a validation failure

[terrylinooo]

Recording the requests the API refuses turned up a shape nothing had covered,
and it was being classified wrongly.

A rejected parameter answers 422 with a message and a per-field errors bag:

{"message": "The given data was invalid.", "errors": {"urls.0.type": ["The selected urls.0.type is invalid."]}}

That shape has no msg key, so the dispatcher reads it as the single-URL
format — which had no 422 branch. It fell through to the catch-all and was
reported as a ServerException. The batch format has always mapped 422;
this one was simply missing it.

The cost was not only a wrong label. A caller catching ValidationException to
tell a user which field was wrong caught nothing, and the fields themselves
were never read by any branch. It also invites a retry of something that will
never succeed.

Why this took a second round of recording

Requests the API refuses create nothing and cost nothing, which makes them the
cheapest recordings to take — and they are the only way to reach the error
branches a successful run never touches. Two are added here: this one, and the
404 all three endpoints answer when a key cannot be resolved.

The second one closed a real gap. The Node SDK has a check that runs both SDKs
over these same recordings and compares them, and a deliberate mistake in the
batch 404 rule used to pass it untouched, because nothing recorded reached
that branch. It fails now.

Worth noting what that check could not do: both SDKs classified the 422
identically, because both were wrong in the same way. Comparing implementations
catches drift between them; only recording catches them drifting together from
the service.

The plan records both findings in §0.4.

🤖 Generated with Claude Code