Fix cross-environment API-surface drift and lint findings from CI

extract_api.py's own extraction wasn't deterministic across machines, which
CI's drift check caught immediately: JSON_HAS_RANGES auto-detects via the
standard library's __cpp_lib_ranges feature-test macro, which isn't reliably
gated to C++20 mode by every stdlib -- undefined under -std=c++17 with macOS's
libc++, but defined under the identical flag with the Ubuntu stdlib CI uses,
so parse()/accept()/from_*() extracted different signatures purely depending
on which machine ran the extraction. Pinned to -DJSON_HAS_RANGES=0: the
deterministic and safe choice, since pinning to 1 was tried first and found to
fail to parse on a stdlib without full <ranges> support even when the macro
claims otherwise.

Also found and fixed a second, independent source of the same class of drift:
get_identity_name() used cursor.spelling verbatim for CONVERSION_FUNCTION
cursors, which libclang renders as its own internally-canonicalized form of
the return type rather than what's literally written. Confirmed for
json_pointer::operator string_t() spelling differently on two machines
pinned to the identical libclang==18.1.1 wheel, with the JSON_HAS_RANGES fix
above ruled out as the cause. Now derived from the cursor's own raw source
text instead, immune to libclang's dependent-type resolution differences and
incidentally more readable than the libclang-internal forms it replaces.

Bumped SURFACE_FORMAT_VERSION to 3 and regenerated all 27 history snapshots
and the committed api_surface.json; both fixes are documented in
tools/api_checker/history/README.md's format-history log.

Also fixes diff_api.py's format_version guard, which only compared the two
loaded surfaces against each other and never against SURFACE_FORMAT_VERSION
(what this build actually understands) -- two surfaces on the same,
newer-than-expected format_version would have silently passed the guard.

Remaining fixes are the concretely actionable findings from Codacy's review
of the new tools/api_checker/ files: unused imports/variables, a stray
f-string with no placeholders. Left the docstring-formatting nitpicks
(pydocstyle D2xx/D4xx) and generic subprocess-usage notices alone -- the
former has no established convention elsewhere in this codebase's Python
tooling to conform to, and the latter are inherent to a dev tool that shells
out to git/clang with developer-controlled arguments, not user input.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Niels Lohmann <mail@nlohmann.me>

tools/api_checker/api_surface.json

@@ -1,5 +1,5 @@
 {
-  "format_version": 2,
+  "format_version": 3,
   "meta": {
     "extracted_from": "include/nlohmann/json.hpp"
   },
@@ -1472,7 +1472,7 @@
       "tier": "type"
     },
     {
-      "identity_name": "operator nlohmann::detail::value_t",
+      "identity_name": "operator value_t",
       "kind": "CONVERSION_FUNCTION",
       "name": "operator nlohmann::detail::value_t",
       "pretty_signature": "nlohmann::basic_json::operator nlohmann::detail::value_t",
@@ -1481,7 +1481,7 @@
       "tier": "callable"
     },
     {
-      "identity_name": "operator type-parameter-1-0",
+      "identity_name": "operator ValueType",
       "kind": "FUNCTION_TEMPLATE",
       "name": "operator type-parameter-1-0",
       "pretty_signature": "nlohmann::basic_json::operator type-parameter-1-0",
@@ -2381,7 +2381,7 @@
       "tier": "callable"
     },
     {
-      "identity_name": "operator nlohmann::json_pointer::string_t_helper<type-parameter-0-0>::type",
+      "identity_name": "operator string_t",
       "kind": "CONVERSION_FUNCTION",
       "name": "operator nlohmann::json_pointer::string_t_helper<type-parameter-0-0>::type",
       "pretty_signature": "nlohmann::json_pointer::operator nlohmann::json_pointer::string_t_helper<type-parameter-0-0>::type",