Add features for 26.1's string-mapped client_command and use_entity ids

[u9g]

26.1's protocol maps two more serverbound action ids to strings, the way entity_action already does since 1.21.6:

"packet_client_command": ["container", [{"name": "actionId", "type": ["mapper", {"type": "varint", "mappings": {"0": "perform_respawn", "1": "request_stats", "2": "request_gamerule_values"}}]}]]
"packet_use_entity":     ["container", [{"name": "target", "type": "varint"}, {"name": "hand", "type": ["mapper", {"type": "varint", "mappings": {"0": "main_hand", "1": "off_hand"}}]}, ...]]

A client that keeps writing the numeric id gets SizeOf error for undefined : 0 is not in the mappings value and the packet is never sent, so on 26.1 mineflayer currently cannot respawn or right-click an entity at all. These two features let it pick the right shape the same way entityActionUsesStringMapper does.

Checked against every pc protocol.json in this repo: client_command.actionId and use_entity.hand are mappers on 26.1 only.

Data only, no code changes. Consumed by PrismarineJS/mineflayer#4077.

[u9g]

PrismarineJS/mineflayer#4076 reads the declared form straight out of protocol.json (lib/protocol_enum.js), so it handles client_command.actionId on any version without a feature flag, and these two features are not needed for it.

The useEntityHandIsString half also cannot land together with #1278, which takes use_entity.hand back to a plain varint: whichever of the two merges second makes the other wrong. #1278 + #4076 covers both fields — #1278 for use_entity.hand, which #4076 does not touch, and #4076 for client_command.actionId.

[u9g]

#1278 takes the opposite approach for the same field: it drops 26.1's use_entity.hand mapper instead of describing it. Only one of the two should land; this one also covers client_command.actionId, which #1278 leaves mapped.

[u9g]

PrismarineJS/mineflayer#4077 now reads the shape out of the schema instead of asking for a feature, so it is correct whether 26.1 keeps these mappers or #1278 removes them. That leaves this PR without a consumer; closing in favour of settling the data question on #1278.