prop_array_add_uint{8 16 32 64} stores unsigned values via signed creator breaking roundtrip semantics

Summary

TEMPLATE(size) macro generates prop_array_add_uint{8 16 32 64} using prop_number_create_integer((int64_t)val) at line 187 copy-paste from add_int sibling at line 171. Parallel prop_array_set_uint{8 16 32 64} at line 155 correctly uses prop_number_create_unsigned_integer((uint64_t)val) and so does prop_dictionary_set_uint in sibling prop_dictionary_util.c:167. Any unsigned value whose high bit relative to width is set stored as SIGNED prop_number and matching prop_array_get_uint##size rejects it due to prop_number_unsigned(num)==false && prop_number_integer_value(num)<0 guard. Pure logic/correctness bug no demonstrated security impact. TEMPLATE instantiated 4 times (lines 196-199) all four widths affected. Only in-tree kernel callers dm_ioctl.c:658 (add_uint64 with 32-bit udev_t high bit never set) dm_target.c:246 (add_uint32 small version always <INT32_MAX). Latent risk future caller storing attacker-influenced unsigned via add_uintN reading back via get_uintN gets false return or uses uninitialized stack variable.