Bound UBJSON optimized arrays of a valueless type

[nlohmann]

Closes #2793. Also the root cause of the OSS-Fuzz out-of-memory and timeout reports for parse_ubjson_fuzzer (issues 42506968 and 42506917, both open since January 2022).

What

An element of type 'Z' (null), 'T' (true) or 'F' (false) is encoded by its type marker alone, so an optimized UBJSON array of one of those has no payload: reading an element consumes no input at all. Its declared count is therefore the only thing that decides how much is allocated, and nothing bounded it.

[$Z#l plus a four-byte count is nine bytes of input describing two billion values. #2793 reports 35 GB and 150 seconds from ten bytes of input.

Everything else is already bounded by the end of the input, because it costs at least one byte per element:

• 'N' (no-op) is skipped rather than stored
• objects are safe — every element is preceded by its key, which costs bytes
• BJData already refuses these markers as an optimized type, so this is a plain UBJSON matter

How

Reject a count above 1,048,576 elements for those three types with out_of_range.408, the code this reader already uses for a declared size it will not honour. The check runs before the SAX start event, so no container is opened and then abandoned.

Rejecting on the read side alone would break the guarantee that anything to_ubjson() writes can be read back, and would trip the round-trip assertion in fuzzer-parse_ubjson.cpp. So the writer falls back to the unoptimized encoding, one byte per element, for arrays of these types above the same limit. Its decision depends only on the array's size, which is identical for a value and for anything parsed back from it, so the round trip is stable:

json j(1048577, nullptr);
json::from_ubjson(json::to_ubjson(j, true, true)) == j;   // still true

Verification

The #2793 payload is now rejected in 0 ms instead of allocating tens of gigabytes. At the limit the optimized form is still used (9 bytes for a million nulls); one past it the writer emits the unoptimized form and it still round-trips. No existing test changes: the largest such count in the test suite is 65,793.

API impact

No breaking changes to the public API. One accepted-input change: a plain UBJSON array of $Z/$T/$F declaring more than 1,048,576 elements is now rejected with out_of_range.408 instead of being materialised. Documented in exceptions.md and ubjson.md.

Checklist

• The changes are described in detail, both the what and why.
• If applicable, an existing issue is referenced.
• The Code coverage remained at 100%. A test case for every new line of code.
• If applicable, the documentation is updated.
• The source code is amalgamated by running make amalgamate.

🤖 Generated with Claude Code

[gregmarr]

Put (1 << 20) or (0x100000) next to the decimal number so that it's obvious it's a "nice round number" in binary and hex domains? Also applies in other .md file.

[nlohmann]

Good idea — added (1 << 20) next to the decimal number in both spots (here and the matching text in exceptions.md), matching how max_valueless_container_size is actually defined in binary_reader.hpp. Pushed.