Preserve 32-bit width when writing negative binary integers

[fhgffy]

Summary

Preserve the 32-bit bit pattern when writing negative CONFIG_TYPE_INT values in binary format.

On the current base, v = 0b10000000000000000000000000000000; reads as a 32-bit integer with value -2147483648. Writing it passes that negative value to an int64_t formatter, which sign-extends it and emits 64 binary digits. Reading the generated configuration then fails with a syntax error.

Convert through uint32_t before calling the formatter. This keeps the 32-bit representation while leaving the parser, INT64 writer, and other formats unchanged.

The regression checks exact output, EOF, parsed type/value/format, and both per-setting and configuration-default binary formatting for INT32_MIN, INT32_MIN+1, -2, -1, 0, 1, and INT32_MAX.

Validation

Tested on Linux x86_64 with GCC/G++ 14.2.0 and CMake 3.31.6, based on 1e2dedd046f5119e67b0ccbda5916e8aff55c142:

• Clean baseline: all 17 native tests pass
• New regression on unchanged implementation: fails on the 64-digit output
• Patched implementation: all 18 native tests pass; C/C++ libraries and examples build
• ASan/UBSan: full native suite passes with ASAN_OPTIONS=detect_leaks=0; leak checking was not performed
• Additional C++ probe: 32 nested, format, and positive-INT64 round trips pass
• Additional public C harness: 1,077 cases pass, covering nested containers, deterministic 32-bit patterns, explicit/default formats, HEX/decimal neighbors, positive-INT64 boundaries, and file APIs; a C++ wrapper check also passes
• The same harness fails against a freshly built untouched base, confirming the width regression
• git diff --check passes

Windows, macOS, 32-bit hosts, embedded targets, fuzzing, and Autotools builds were not tested locally. autoreconf was unavailable.

Scope

This fix is separate from #302 (integer-to-double setters) and pending #303 (explicit L/LL suffix parsing). Neither patch is included here.

Existing negative INT64 binary output remains unreadable on this base, and explicit-L positive values between INT32_MAX+1 and UINT32_MAX still parse incorrectly without #303. Those behaviors are unchanged by this patch; this does not fix every binary integer round trip.