Copy-construct the base class of a deep copy's elements, not assign it

[nlohmann]

Summary

The bounded-descent deep copy added by #5389 builds the elements of a copy nested
past the 128-level bound by default-constructing them and then having
copy_metadata() assign their base class afterwards. That assignment path is
only reached at runtime for values nested past the bound, but since it is
called (unconditionally in the source) from copy_structured(), which every
copy constructor call compiles, the assignment gets instantiated for every
copy regardless of depth. A CustomBaseClass that is copy-constructible but
not move-assignable (for example one with a const data member) therefore
could no longer be copied at all, even at the top level.

Changes

• copy_array_level() and copy_object_level() now build each element with a
  new private-tag-selected constructor, basic_json(copy_construct_tag, const basic_json&),
  that copy-constructs the base class directly (and, under
  JSON_DIAGNOSTIC_POSITIONS, copies the positions), the same way the regular
  copy constructor already builds elements within the 128-level bound.
• copy_shallow() no longer calls the now-removed copy_metadata(); it only
  fills in the leaf value or defers to the worklist, since the base class and
  positions are already set by the constructor above.
• The constructor is public (an allocator's emplace_back()-driven
  construction happens outside basic_json's own member functions and so
  cannot call a private one), but its tag type stays a private nested type,
  so outside code can never obtain a value of it to call the constructor.
• Regenerated single_include/nlohmann/json.hpp.

Tests

Added a regression test to tests/src/unit-custom-base-class.cpp using a
custom base class with a const member (copy-constructible, not
copy-/move-assignable), copied both at the top level and nested 300 levels
deep (past the 128-level bound), checking the base class's data is preserved
at every level. Built the new test once against develop's pre-fix headers to
confirm it fails to compile there with the exact error from the issue, and
against the fixed headers to confirm it compiles and passes.

Also built and ran the issue's own reproduction program against the fixed
headers (prints 2 7, matching headers from 56b3ee566^), and
tests/src/unit-diagnostics.cpp / tests/src/unit-diagnostic-positions.cpp
(including with JSON_DIAGNOSTICS=0) to confirm JSON_DIAGNOSTICS parent
pointers and JSON_DIAGNOSTIC_POSITIONS metadata are still copied correctly.

Configurations run: clang++ with -std=c++11 and -std=c++17,
-fsanitize=address,undefined, -Wall -Wextra -Werror; and g++ 16 with
-Weffc++ -Wnoexcept (both CI-relevant flags noted for this kind of change).

Public API

No breaking changes. This restores the behavior documented for
CustomBaseClass (copy construction requires only a copy-constructible base
class) and in place before #5389; copy assignment is unchanged and still
requires an assignable base class.

Fixes #5674

---

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

🤖 Generated with Claude Code

[nlohmann]

Merged develop (8366d86). Conflict in copy_array_level(): develop's #5721 now sets the array type right after create<array_t>(), and this PR replaced resize() with the copy_construct_tag emplace_back loop. The merge keeps both: create the array, set value_t::array, then emplace the elements. single_include regenerated.

— posted by Claude Code on behalf of @nlohmann