Fix getBodyPartName bounds checks

[HeresHavi]

Summary

Fix the client and server bounds checks used by getBodyPartName. Body part IDs are now rejected before they can index past the 10-entry name tables.

Motivation

The body part name tables contain 10 entries, with valid indexes from 0 to 9, but the existing checks also accepted ID 10. On the client, this reached the fixed-array bounds assertion. On the server, it read past the raw array and returned an unintended string instead of false.

For example, a client resource calling getBodyPartName(10) could assert the player's client. The same call from a server resource could return data from outside the body part name table.

The updated checks reject ID 10 before accessing either table. Valid IDs from 0 to 9 keep their existing behavior, and invalid IDs return false.

Test plan

Runtime

• Before Fix: On official 1.7-untested-26702, client-side getBodyPartName(10) triggered the uiIndex < SIZE assertion in SharedUtil.Misc.h. Server-side getBodyPartName(10) returned an unintended string with a length of 6 instead of false.
• After Fix: On patched Debug and Release builds, client-side and server-side getBodyPartName(10) returned false. No assertion, crash, or unintended server result occurred.
• Valid Case: getBodyPartName(9) returned Head. ID 11 returned false, confirming that existing rejection behavior remains unchanged.

Builds and Tests

• Debug | Win32: Build passed, 304 client tests passed.
• Release | Win32: Build passed, 304 client tests passed.
• Debug | x64: Server build passed.
• Release | x64: Server build passed.
• Ran clang-format.

Checklist

• Your code should follow the coding guidelines.
• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.