pc 26.3: add entityDelta type for the new stepped entity-move encoding

[DallasCarraher]

Summary

26.3 replaced ClientboundMoveEntityPacket's (rel_entity_move / entity_move_look) flat 3x-i16
delta with a packed properties varint (bit 0 = onGround, remaining bits = stepCount) followed
by either the old flat format (stepCount <= 0) or stepCount chained
{ticks: varint, dX, dY, dZ: i16} DeltaStep entries used for smoother client-side interpolation
when the server batches more than one tick's movement into a single packet.

Without this, minecraft-data's 26.3 schema (see paired PR
minecraft-data#1301) still assumed
the old flat format, so almost every entity-movement packet was silently misparsed as soon as
there was more than one nearby entity -- flooding the console with
Chunk size is N but only M was read ; partial packet : rel_entity_move /
PartialReadError.

The step count depends on a value derived from properties at parse time (properties >>> 1),
which plain protodef container/switch/countType can't express (those only reference a
sibling field's raw value, not a transform of it). This adds a native entityDelta type
(read/write/sizeOf, registered in both the interpreted and compiled datatype tables) following
the existing UUID/restBuffer/entityMetadataLoop custom-type pattern, exposing a uniform
{ onGround, steps: [{ dX, dY, dZ, ticks }] } shape regardless of which wire variant was used.

Root cause found by decompiling VecDelta, VecDelta$Stepped$DeltaStep,
ClientboundMoveEntityPacket (.Pos/.PosRot) and their packProperties/unpackStepCount
static helpers in the real 26.3 server jar (javap -c -p), continuing the precedent from
mineflayer#3888.

Depends on / paired with:

• minecraft-data#1301 (schema
  referencing this type via packet_rel_entity_move.move / packet_entity_move_look.move)
• mineflayer fix updating lib/plugins/entities.js to consume packet.move.steps (PR to follow)

Test plan

• Unit roundtrip test of entityDelta read/write/sizeOf against synthetic linear and
  multi-step buffers, including the exact dX:769, dY:-145 values from the original crash
  report.
• Verified end-to-end against a local offline-mode 26.3 server with several bots + existing
  mobs constantly moving: thousands of rel_entity_move/entity_move_look packets and
  hundreds of stepped sync_entity_position packets parsed with zero
  Chunk size is ... was read warnings, entity positions tracked sanely (no NaN/drift).
• Verified against a real Mojang Realm running 26.3: bot stayed connected, tens of thousands
  of rel_entity_move/entity_move_look packets (including real multi-step packets with
  ticks > 1) and hundreds of sync_entity_position packets, zero warnings for these packet
  types.