fix(api)!: each binary datapoint refusal has the type its status calls for

[JosteinGj]

What

Every refusal on POST /timeseries/data/binary had the type datapoint-block-rejected, whether it answered 400, 404, 413, 415, 422 or 429. RFC 9457 §4 says a problem type documents the one status it is used with, so each status now gets its own type:

Status	Type	reason values
400	invalid-frame	the 13 frame-format reasons (unsorted, schema-mismatch, …)
404	unknown-timeseries	unknown-timeseries
413	request-too-large (existing)	frame-too-large, too-many-frames, request-too-large
415	unsupported-media-type (existing)	unsupported-content-encoding
422	value-type-mismatch / external-id-mismatch	same as the type
429	too-many-in-flight	too-many-in-flight

• Unchanged: reason, frameIndex, timeseriesIds and every status stay as they were.
• Reused types: the 413s use request-too-large, the type the size-limit filter already sends for an oversized body on this same endpoint. The 415 uses the same type as a wrong Content-Type.
• Titles: each title now describes its type.
• Retry: too-many-in-flight is explicitly retry: same-request instead of being derived from the status.
• Schema: the endpoint's error responses name a new DatapointBlockProblem schema, ApiProblem lists the new types, and a test fails if any type constant in Problems is missing from that list.

Compatibility

This breaks anything matching type == ".../datapoint-block-rejected". I found no code that does. The Java SDK (BinaryDatapointIngestor) and the Rust SDK (src/timeseries/binary.rs) check the status plus the substring unknown-timeseries or external-id-mismatch in the body. Both strings are still in reason, and each is now also its type's slug.

Docs (datahub-sdk-docs)

Updated in IntelliStream-DataHub/datahub-sdk-docs#80, to merge after this ships:

• reference/binary-datapoints.md: §Responses (example, table with a type column) and the §Caps row for the compressed body.
• reference/limits.md: summary table, §Request body size, §Binary frame caps. §Request body size already said a raw oversized body got datapoint-block-rejected; the filter has always sent request-too-large, so that is fixed there too.
• reference/client.md: the binary row of the status table.

reference/timeseries.md and the SDK-behaviour table in limits.md use only reason strings and stay true.

Suggested doc pages for the new types, if type URIs are made to resolve:

• invalid-frame, value-type-mismatch → binary-datapoints#responses
• unknown-timeseries, external-id-mismatch → binary-datapoints#retrying
• too-many-in-flight → limits#binary-frames

This is one of four independent problem-type PRs (binary, file restore, file path collisions, upload 403). They merge cleanly with each other in any order. ./gradlew :datahub-api:test passes.

🤖 Generated with Claude Code