Fix use-after-free in cJSONUtils_SortObject: restore child->prev tail invariant

[nvnzno-a11y]

Issue

Fixes #1090 — use-after-free (8-byte pointer write) reported by ReisterJ with a minimal three-call PoC (cJSONUtils_SortObject → cJSON_DeleteItemFromObject → cJSON_AddItemToObject).

Root cause

sort_list() rebuilds an object's doubly linked child list with mergesort but never restores cJSON's list invariant that the head's prev pointer references the list tail. The parser establishes it (head->prev = current_item in cJSON.c) and add_item_to_array() consumes it via suffix_object(child->prev, item) for O(1) appends. After a sort, child->prev is stale — NULL or a live interior node. Deleting that interior node leaves child->prev dangling, and the next append writes prev->next = item into freed heap memory (and silently drops the new item when prev is NULL).

Fix

After the merge completes, walk to the end of the merged list once and set result->prev to the tail. One extra O(n) pass per sort_list call, negligible next to the O(n log n) sort itself. All other prev links are already maintained by the merge.

Verification

• Reporter's PoC on current master (6d9f244): child->prev no longer equals the tail after cJSONUtils_SortObject, and a custom allocator harness (poison-on-free) observes the stale write into the freed node. On the patched build the invariant holds, the appended item lands at the tail, and no write touches a freed block.
• New regression test sort_object_should_restore_prev_tail_invariant in tests/misc_utils_tests.c checks child->prev == tail after sorting and after a delete+add sequence. It fails on the unpatched build and passes with the fix.
• Additional standalone battery verified sort correctness and full prev-chain integrity (forward and backward walks) across 10 cases: sorted/reversed/duplicate keys, case-sensitive and case-insensitive, nested objects, and append-after-sort.