[DustinReynoldsPE]

Summary

remap_inbound skips ClientboundGamePacket::SetPlayerInventory, so its item
stack keeps the wire-version id decoded through the native registry table on
any translated connection. Between 26.2 (native) and 26.3, 1465 item ids
shifted; e.g. a server-sent iron_shovel (26.3 id 1046) decodes as
milk_bucket and oak_log (163) as birch_log.

This is the same class of bug as #664 (set_entity_data), one packet over:
set_player_inventory is how servers sync hotbar/player-inventory slots in
26.x (it replaced container_set_slot with container_id = -2).

Impact on non-native servers

• Tools mine at bare-hand speed. destroy_progress resolves the Tool
  default component by ItemKind; a wrong kind has no Tool default, so
  mining speed falls back to 1.0. Reported against a 26.3 server: an iron
  shovel broke dirt no faster than an empty hand.
• Wrong item icons in the hotbar/inventory for any item whose id shifted
  between the wire and native versions (often subtle, e.g. log variants
  mapping to other logs).

Fix

Add the missing arm calling remap_stack on p.contents, matching the
adjacent ContainerSetSlot/SetCursorItem/SetEquipment handling.

This completes the item-carrying packet coverage; the only remaining
unremapped paths are advancement icons (existing TODO) and commands
brigadier suggestions, both cosmetic.

Test plan

• cargo test -p pomme-client player_inventory_item_remaps_777 — new
  wire-level regression test: a 26.3 set_player_inventory frame carrying
  item id 163 decodes to ItemKind::OakLog after remap, not BirchLog.
• cargo test -p pomme-client remap — all remap tests pass.
• cargo fmt --all --check clean.
• Verified live against a 26.3 server: iron shovel mines dirt at tool
  speed again after the fix.

[Purdze]

Thanks for this. This was sorted via #722