fix(engine): anchor content search to obj_start in parse_messages_json

[somtri]

Fixes #757.

parse_messages_json searches for "role" starting at the message object's opening brace, so it finds the role key regardless of where it appears in the object. The search for "content", however, started from the end of the parsed role value instead of the same starting point. When a message object serializes content before role (legal JSON, since key order isn't semantically significant, and something an unordered-map serializer such as Swift's JSONSerialization can produce), the content key sits earlier in the string than the search start, so it's never found within the object's bounds and msg.content is silently left empty.

This anchors the content search to obj_start, matching how role and the images/audio path arrays already search. The existing content_pos < obj_end bound is unchanged, so the search still can't cross into a later message object.

Added cactus-engine/tests/test_parse_messages.cpp, a standalone suite (no model weights needed) covering role-first order, content-first order, escaped content, mixed ordering across a multi-message array, and content-first with image/audio paths attached. Confirmed the content-first case fails on the unpatched function and passes after the fix.

Built and ran the full cactus-engine test component (all 15 targets) on an ARM64 Linux environment. No new failures. Two pre-existing, unrelated issues were investigated and ruled out as caused by this change: test_index needs CACTUS_INDEX_PATH set when run directly (passes once set); test_telemetry's concurrency race test fails identically on the unpatched tree (confirmed by reverting the fix and rerunning), most likely a timing margin issue under emulation, not related to this diff.