Fix crash: bounds-check Localization binary decode against out-of-bounds reads

[ankuper]

Why

Localization.init(from:) parses a length-prefixed binary blob with no validation: ReadBuffer.read() does a raw memcpy with no bounds check against the buffer's actual length, and for _ in 0 ..< count traps with a negative count. Every length-prefixed string field in this parser (key, plural forms, single value) is read the same unchecked way.

This buffer is persisted (and can arrive via a server-pushed localization update), so a truncated or corrupted record crashes on decode — and crash-loops on every subsequent relaunch, since the bad record stays in Postbox. Confirmed on-device: SIGTRAP, with procLaunch showing an app instance that had been running over an hour before the first crash, followed by an instant relaunch that crashed again ~40s later hitting the same record.

Fix

Added a small readLengthPrefixedData() helper used for every length-prefixed read in the parser. It validates the offset against the buffer length before reading the 4-byte length prefix, and validates length >= 0 and that the resulting slice stays in bounds before reading the payload — returning nil (which aborts the parse, keeping whatever entries were already decoded) on any violation.

Behavior for already-valid-but-garbled data is unchanged: a length-prefixed read that is in bounds but decodes to invalid UTF-8 still just drops that one entry and the loop continues, exactly as before — only real out-of-bounds/negative-length reads abort the parse now.

Testing

Verified against the crash report that triggered this (SIGTRAP, trap point consistent with either the 0 ..< count Range precondition or an out-of-bounds Data(bytes:count:) read). Built and ran on-device (iPhone, iOS 26.5); localization loading works normally post-fix, no regression in displayed strings.