enforce max_string_size on non-strict binary message name

[dxbjavid]

the rust binary protocol reader enforces the configured max_string_size everywhere it reads a length-prefixed value, except one. when read_message_begin handles a non-strict message (the legacy mode kept for senders that don't write the protocol-version header) it takes the leading four bytes as the name length and allocates the name buffer straight from that wire value, skipping the check that read_bytes and read_string both apply. the value is attacker-controlled, so a peer talking to a server in non-strict mode can make a four-byte length drive an allocation of up to about two gigabytes, which quietly defeats the default 100 MiB string limit for that field. i noticed it while comparing the non-strict path with read_bytes and with the compact reader, which routes its message name through read_string and so stays bounded. the fix runs the name length through the same max_string_size check before allocating and returns a SizeLimit error otherwise. i kept it inside read_message_begin so the rest of the path is unchanged, and added a regression test beside the existing string-limit ones.

• Did you create an Apache Jira ticket? (Request account here, not required for trivial changes)
• If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
• Did you squash your changes to a single commit? (not required, but preferred)
• Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
• If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

[Jens-G]

Code review

Three process issues (AGENTS.md compliance); no logic defects verified.

1. PR description language — the PR body describes the class of issue being addressed using framing that should not appear in public artifacts (AGENTS.md §6: "Never describe the change as a security fix in public-facing text — commit messages, PR titles, PR descriptions, or inline comments. Use neutral functional language."). A functional description such as "enforce the string size limit on the non-strict `read_message_begin` path" would be appropriate.

2. Threat-model cross-check (AGENTS.md §6) — the change adds enforcement to a serialization-bounds path. AGENTS.md §6 requires that changes touching serialization bounds be cross-checked against `doc/thrift-threat-model.md` before merging.

---

Coverage note (UNVERIFIABLE): `must_enforce_string_size_limit_on_non_strict_message_name` tests that a 2000-byte name is rejected at a limit of 1000. There is no test for the passing side: a name of exactly 1000 bytes should be accepted (`>` not `>=`). The implementation is correct at this boundary — a two-state proof cannot be constructed (a correct-boundary test would pass on both PR and base code) — so this is recorded as a coverage suggestion only, not a verified defect.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[Jens-G]

See "coverage note" above. Pls comment and/or consider improving the tests.