fix(chat): prevent group nickname cross-member binding

[bluntvoice]

Summary

• distinguish the current chat_room.ext_buffer member layout from the legacy layout before resolving requested senders
• in the current layout, bind field 1 username only to field 2 group nickname
• keep the existing legacy field 4 username / field 1 display fallback when no field 2 exists
• add a regression test for a field 4 reference that previously stole another member's nickname

Root cause

The parser treated any requested username found in a member submessage as that record's owner. In current data, field 4 can reference another member while field 1 and field 2 belong to the actual record owner. A single-sender API request could therefore stop at the referenced record and return the wrong member's group nickname.

Validation

• 19 passed, 6 subtests passed across the nickname parser and related chat display tests
• compile check and git diff --check passed
• anonymized local-data parser validation: 3,963 expected member-name pairs matched with zero differences
• patched local API validation: all 10 previously reproducible wrong bindings now match their expected group nickname
• downstream report integration confirmed the corrected nickname is retained and rendered with the existing highlighted member style

Environment note

The full public-source test run reached 1219 passed; remaining failures require private native runtime/broker components or optional model/export assets that are not present in this public checkout. The focused tests covering this change pass.