Write protocol enum fields by name where the version maps them

[u9g]

bot.activateEntity, bot.respawn and bot.wake send nothing on the versions whose schema describes the field as a mapper.

• 26.1 maps use_entity.hand (main_hand/off_hand) and client_command.actionId (perform_respawn/request_stats/request_gamerule_values).
• 1.21.6+ maps entity_action.actionId, which bed.js writes as 2.
• game.js wrote the post-win_game respawn as { action: 0 }; no version has an action field on that packet.

protodef's compiled mapper writes the name and throws on anything else (ProtoDef-io/node-protodef#176), so each of these raises SizeOf error ... is not in the mappings value on the serializer stream and the packet never reaches the server. Before that change the numeric form happened to serialize to the same bytes, so nothing on the wire changes here.

enumField(registry, packet, field, index) returns the mapped name when the version's schema maps the field and the index otherwise.

Two regression tests in test/internalTest.js drive activateEntity and respawn against the mock server, which parses what the bot writes, so a value the serializer rejects fails the test. Also checked against a live 26.1 server (JartexNetwork, ViaVersion): right-clicking an NPC raised the serializer error and did nothing before the change, and completes the interaction after it.

[github-actions]

Tests more than 1.5x slower than master (durations are noisy, so this is informational):

   5178ms ->   12709ms  mineflayer_external 1.19.3v nether
   8080ms ->   13690ms  mineflayer_external 1.19.4v nether

[u9g]

Closing as a duplicate: #4076 and #4077 came out of parallel sessions on the same bug a little earlier and cover the same call sites (client_command, entity_action, game.js's action field), with use_entity handled by a fixup on #4066. Nothing here is additional.

[extremeheat]

The more correct thing to do is fix the data by making it consistent upstream. Alot of the features for this kind of thing are code smells

[extremeheat]

Could be worthwhile to make a script that verifies that between all the versions that an identically named field doesn't switch between integer and mapper type. That would make it easier to fix. Could be added to a protocol test too to catch this kind of thing