Fix EitherHolder item data components (damage_type, chicken/variant, zombie_nautilus/variant) for 1.21.11

[atiweb]

Problem

Three 1.21.11 item data components are encoded on the wire with EitherHolder.streamCodec (net.minecraft.world.item.EitherHolder):

• minecraft:damage_type — EitherHolder<DamageType>
• minecraft:chicken/variant — EitherHolder<ChickenVariant>
• minecraft:zombie_nautilus/variant — EitherHolder<ZombieNautilusVariant>

EitherHolder.streamCodec is ByteBufCodecs.either(holderCodec, ResourceKey.streamCodec): a boolean, then either the holder or a resource-key string. For all three, the holder codec is ByteBufCodecs.holderRegistry(...), which writes a plain VarInt registry id (reference only — no inline value and no id + 1).

They were defined as registryEntryHolder, which reads the holder as VarInt(n) and returns n - 1, and treats n == 0 as an inline value. That is off by one for every referenced holder, and desyncs on holder id 0.

Evidence (real 1.21.11 server)

A stone_sword[minecraft:damage_type="minecraft:player_attack"] is sent in container_set_content as the component bytes 08 01 22:

• 08 = SlotComponentType damage_type
• 01 = hasHolder = true
• 22 = holder id 34

The server's damage_type registry has minecraft:player_attack at id 34. The old registryEntryHolder decoded it as 34 - 1 = 33 = minecraft:outside_border (wrong). The fixed structure decodes damageType = 34 = minecraft:player_attack.

Fix

Define the holder branch as a plain varint (matching holderRegistry), keeping the leading hasHolder boolean and the false → string (resource key) branch:

hasHolder: bool
<value>: hasHolder ?
   if true: varint
   if false: string

Applied to damage_type, chicken/variant and zombie_nautilus/variant in data/pc/latest/proto.yml (used by 1.21.11) and rebuilt data/pc/1.21.11/protocol.json. The now-unused DamageTypeData type is removed.

The other variant components are intentionally left unchanged: pig/cow/frog/horse/variant use holderRegistry (already a plain varint); wolf/cat/painting/variant use their own variant stream codecs and are not EitherHolder.

[atiweb]

Extended this to 1.21.6, 1.21.8 and 1.21.9 — chicken/variant has been an EitherHolder item data component since chicken variants were added, not only in 1.21.11. Verified against each version's official server jar (Chicken references EitherHolder in all of them; 1.21.10 shares 1.21.9 via dataPaths.json), and the chicken/variant definition is now identical across 1.21.6–1.21.11.

While at it I checked the other registryEntryHolder variant/holder components against the jars so nothing is missed:

• painting/variant and the entity-metadata chicken_variant are plain Holders (the only EitherHolder use in Chicken is the data component) — correctly left as registryEntryHolder.
• instrument / jukebox_playable / provides_trim_material are already modeled with the hasHolder bool + switch.

So this should cover every EitherHolder case across 1.21.6–1.21.11.

[extremeheat]

Conflicts, please merge in latest master and update PR after npm run build

[extremeheat]

This doesn't apply to 26.1 ?

[atiweb]

Merged master and reran npm run build — all green now.

One note on how I resolved the conflict in pc/latest/proto.yml: master gave 1.21.11 its own proto.yml and repointed pc/latest at 26.1, and these components are no longer EitherHolder in 26.1:

// 1.21.11
DataComponentType<EitherHolder<DamageType>> DAMAGE_TYPE = register("damage_type", b -> b.persistent(EitherHolder.codec(...)).networkSynchronized(EitherHolder.streamCodec(...)));
// 26.1
DataComponentType<Holder<DamageType>> DAMAGE_TYPE = register("damage_type", b -> b.persistent(DamageType.CODEC).networkSynchronized(DamageType.STREAM_CODEC));

net.minecraft.world.item.EitherHolder is gone from the 26.1 jar entirely (class removed, 0 references vs 14 in 1.21.11), and chicken/variant and zombie_nautilus/variant were reverted to plain holders too. So I kept master's registryEntryHolder definitions for pc/latest and applied the fix only to data/pc/1.21.11/proto.yml. The PR now only changes 1.21.5–1.21.11.

Unrelated heads-up while I was in there: 26.1's damage_type still carries the hasHolder: bool from the EitherHolder era, which is now a spurious leading byte since it's a plain holder. Happy to send that as a separate PR if useful.