Fix documentation gaps found in a full GitHub Discussions review (#5264)

* 📝 Fix documentation gaps found in a full GitHub Discussions review

Reviewed all 1008 GitHub Discussions (2020-2026) for recurring questions
that better or more visible documentation would have avoided. Adds/expands
documentation for ~26 distinct gaps, including:

- New "Debugging" page collecting natvis, GDB pretty printer, LLDB status,
  and JSON_DIAGNOSTICS pointers (previously scattered/undiscoverable)
- Thread-safety and schema-validation FAQ entries
- StringType's char-based requirement (no wstring/u16string/u32string)
- Brace-initialization-yields-arrays warning directly on the constructor
  reference page (previously only in the FAQ, missed by users reading
  the constructor docs)
- std::any exclusion from get<T>(), with a manual-dispatch example
- Non-string-keyed std::map serializing as an array of pairs
- ordered_json compatibility with NLOHMANN_DEFINE_TYPE_* macros
  (already worked, was undocumented)
- std::array truncation on size-mismatched conversion (no exception)
- static_cast vs. get<std::optional<T>>() divergence
- Recipe for omitting a std::optional field instead of emitting null
- No built-in nesting-depth limit during parsing + a callback-based
  workaround recipe
- Recipe for streaming a large homogeneous array via parser callbacks
- operator>> stream-position semantics for concatenated JSON values
- JSON Pointer array-vs-object creation rule for non-existing paths
- CMake target name (nlohmann_json_modules) needed to link C++20 modules
- ESP-IDF/PlatformIO: no official package, link to a community fork
- get(key, default) as the Python dict.get() equivalent
- reserve() recipe for pre-allocating array capacity
- JSONC as an alias for the existing ignore_comments/ignore_trailing_commas
  combination (distinct from the unsupported JSON5)
- items() dereferenced-element type: decltype() idiom + detail-namespace
  stability caveat
- Various macro/type-conversion limitations (MSGPACK_DEFINE_ARRAY
  equivalent, char-array round-tripping, ADL serializer macro gap)

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

* 🎨 fix format

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

---------

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

docs/mkdocs/docs/home/debugging.md

@@ -0,0 +1,31 @@
+# Debugging
+
+This page collects the library's built-in debugger integrations and other debugging-related features. They are
+not linked from a single place elsewhere in the docs, so are collected here.
+
+## Visual Studio (natvis)
+
+The repository ships [`nlohmann_json.natvis`](https://github.com/nlohmann/json/blob/develop/nlohmann_json.natvis)
+at its root, a [Natvis](https://learn.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects)
+file that gives `json`/`ordered_json` values a friendly, key/value debugger view instead of showing raw internal
+fields, when debugging with the MSVC debug engine (`cppvsdbg`) in Visual Studio or VS Code.
+
+Debug engines that wrap LLDB instead of the MSVC debug engine (for example, `codelldb` in VS Code) only have
+partial/experimental Natvis support, and commonly fall back to showing raw internal fields even with the
+`.natvis` file present. Switching to `cppvsdbg` where available, or checking your debug extension's own Natvis
+support/version, are the next things to try if this happens. There is currently no bundled LLDB-native
+pretty-printer script in this repository.
+
+## GDB
+
+The repository ships a [GDB Python pretty printer](https://github.com/nlohmann/json/tree/develop/tools/gdb_pretty_printer)
+under `tools/gdb_pretty_printer`, with its own usage instructions in that directory's `README.md`.
+
+## Extended exception diagnostics
+
+Defining [`JSON_DIAGNOSTICS`](../api/macros/json_diagnostics.md) before including the library augments
+`type_error`/`out_of_range`-style exceptions with a JSON Pointer to the offending value, which can help pinpoint
+where in a large document a runtime error occurred. This only applies to exceptions thrown *after* a value
+exists (e.g. during element access); parse errors, which happen before any value exists to point at, are not
+covered by this mechanism -- see [Parsing and exceptions](../features/parsing/parse_exceptions.md) for how parse
+errors report their own location instead.