Fix CBOR tag handlers not recognizing tags 0-5 and 21-23

[sahilkamate03]

Fixes #5315.

What changed

• Added the missing case 0xC0-0xC5 and case 0xD5-0xD7 labels to the tagged-item switch in binary_reader::parse_cbor_internal() (include/nlohmann/detail/input/binary_reader.hpp), so the full 0xC0-0xDB` tag-header range is handled the same way.
• Extended the "Tagged values" test in tests/src/unit-cbor.cpp to cover 0xC0-0xD7 (previously only 0xC6-0xD4 was tested) under error, ignore, and store handlers.
• Updated docs/mkdocs/docs/features/binary_formats/cbor.md to state the tagged-item range as 0xC0..0xDB instead of leaving it unspecified.
• Regenerated single_include/nlohmann/json.hpp via make amalgamate.

Why

• CBOR tags 0-5 (0xC0-0xC5: RFC 3339 date/time, epoch time, bignum, decimal, bigfloat) and tags 21-23 (0xD5-0xD7: base64url, base64, base16 conversion hints) are valid major-type-6 tags per RFC 8949, but the switch statement only recognized 0xC6-0xD4 and 0xD8-0xDB.
• The gap made these bytes fall through to the default case and throw parse_error.112 ("invalid byte"), even under cbor_tag_handler_t::ignore and ::store — handlers that are documented to accept any tag. This broke interop with compliant ncoders that use preferred (shortest) serialization, since e.g. tag 23 is encoded as the single byte 0xD7.

Checklist

• The changes are described in detail, both the what and why.
• Code coverage remains at 100% — full suite passes 109/109.
• Documentation updated.
• Source amalgamated via make amalgamate (verified: diff matches the include/nlohmann source change exactly).

Test plan

• cmake -S. -B build && cmake --build build -j10 && ctest --test-dir build -j10 → 100% tests passed, 0 failed out of 109
• test-cbor_cpp11 covers the new 0xC0-0xD7 tag range under error, ignore, and store handlers

[nlohmann]

The tests only wrap a string value for each new tag byte. Might be worth a case wrapping a binary payload under cbor_tag_handler_t::store to confirm 0xC0-0xC5/0xD5-0xD7 take the same "unwrap, don't treat as subtype" path as 0xC6-0xD4 already do.

[nlohmann]

The "Incomplete mapping" warning still lists date/time (0xC0..0xC1), bignum (0xC2..0xC3), decimal fraction (0xC4), bigfloat (0xC5), and expected conversions (0xD5..0xD7) as types that "are not supported and will yield parse errors." That's now only true for the default error handler — under ignore/store these parse fine, same as 0xC6..0xD4/0xD8..0xDB, which were already correctly omitted from this list. Since the PR already updates the "Tagged items" warning just below to say the full 0xC0..0xDB range is tag-handler-dependent, these five bullets should be deleted from the "Incomplete mapping" box to avoid the two warnings contradicting each other.

[nlohmann]

Apologies for the AI-assisted review here — I don't have time for a deeper pass on this one right now, so this is a quick comparison rather than a full re-review.

We got a second PR for the same issue, #5367, which has the identical code fix (same case 0xC0-0xC5 / 0xD5-0xD7 additions in binary_reader.hpp). It also independently fixes the docs issue flagged above — removing the stale "Incomplete mapping" bullets for tags 0-5/21-23 and adding a cross-reference note — which you could port over here.

The other ask from the review above (a store-mode test with a binary payload, not just a string, to confirm the new tag bytes take the same "unwrap, don't treat as subtype" path as the existing ones) is still outstanding in both PRs.

Given this one already has a clean CI run and is otherwise the more complete PR, it's the better one to land — just needs the docs fix and the extra test case.

— posted by Claude Code on behalf of @nlohmann