Give a deep copy its type only after its container exists

[nlohmann]

Summary

When the copy constructor copies a value nested deeper than 128 levels and an allocation fails while it is
copying an inner array or object, the partially built copy ends up with an element typed array/object
but holding a null pointer. That element is already a fully constructed member of its parent's container,
so destroying the parent during stack unwinding dereferences the null pointer (release builds) or fails
assert_invariant() (debug builds), instead of letting std::bad_alloc reach the caller. This also happens
at any depth when JSON_NO_THREAD_LOCAL is defined, since every copy then takes the same iterative path.

Root cause: copy_iteratively() gave a pending worklist element its type right after popping it, before the
next loop iteration created its container in copy_array_level()/copy_object_level(). If create<array_t>()
or create<object_t>() then threw, the element was left typed but empty.

Changes

• Move the type assignment out of copy_iteratively() and into copy_array_level()/copy_object_level(),
  right after the container is successfully created, so a half-built element stays a null value - as
  copy_shallow()'s comment already promised - until it can safely hold one.
• Regenerate single_include/nlohmann/json.hpp (make amalgamate).

Open PR #5585 ("Create a value before giving it its type") fixes the same before-the-value-exists-type
pattern at other places in json.hpp and in to_json.hpp, but does not touch copy_iteratively(),
copy_array_level() or copy_object_level(). This PR is independent of it and fixes the pattern in those
three functions only.

Tests

Added tests/src/unit-allocator.cpp / TEST_CASE("copy of a deeply nested value survives a failing allocation (#5640)"). It builds a value nested 130 levels deep (both arrays and objects, with a
std::map- and an ordered_map-backed object_t), then, for n = 0, 1, 2, ..., lets the n-th allocation of
the copy fail: each such attempt must throw std::bad_alloc (CHECK_THROWS_AS) and leave the source
unchanged (compared against a dump() taken before), stopping once the copy succeeds.

• Fails (crashes) against develop's headers: an assertion failure in debug builds
  (assert_invariant, json.hpp:740); confirmed for both the default build and with
  -DJSON_NO_THREAD_LOCAL (which fails after only a few allocations, since every copy takes the
  iterative path).
• Passes against the fixed headers, built and run for C++11, C++17 and C++20, with
  -fsanitize=address,undefined -fno-sanitize-recover=undefined, plain and with
  -DJSON_NO_THREAD_LOCAL.

Public API

No breaking changes. This only changes the order of two internal, private member functions
(copy_array_level(), copy_object_level(), copy_iteratively()); observable behavior changes only in
that a previously-crashing case (allocation failure during a deep copy) now correctly throws
std::bad_alloc, matching the documented exception safety of the copy constructor.

Fixes #5640

---

This PR was written by Claude Code on behalf of @nlohmann.

🤖 Generated with Claude Code

[gregmarr]

I was very confused about why moving the setting of the type earlier fixed a bug that it was set too early, and then I realized that the current code was setting the type after dst_value was updated to point to the new value which hasn't been processed yet. If it had been before if (worklist.empty()) then it would have been correct.

[nlohmann]

I was very confused about why moving the setting of the type earlier fixed a bug that it was set too early, and then I realized that the current code was setting the type after dst_value was updated to point to the new value which hasn't been processed yet. If it had been before if (worklist.empty()) then it would have been correct.

Yes, I also had to read the diff several times...