Add support for bedrock's dyeable component in the custom item API

[eclipseisoffline]

This PR adds support for bedrock's minecraft:dyeable item component in the custom item API. This closes #6391.

The PR adds this option to CustomItemBedrockOptions, as on Java, this property is not defined through item components, but through the minecraft:crafting_dye recipe type. Note that Java does have minecraft:dye and minecraft:dyed_color components, but, these hold the item's dye (used in the aforementioned recipe), and the item's dyed colour (the colour of e.g. leather armour), respectively.

The minecraft:dyeable item component on bedrock holds a single colour, the default colour of the item. This is represented in the API as an OptionalInt: when present, the item is marked as dyeable, and the value is the item's default colour (in single-integer RGB24 format). When empty, the item is not marked as dyeable. In the interface's builder, the default colour can be specified as a single integer, or as 3 separate R, G, and B components, for convenience.

In item mappings, the component is read as a hexadecimal string, which may or may not be prefixed with a #. For example:

"bedrock_options": {
  "dyeable": "#ff8040"
}

or,

"bedrock_options": {
  "dyeable": "bebebe"
}

The new API methods are noted in the Javadocs as @since 2.10.1, however, the version of Geyser has not yet been bumped, as I expect this will be done in a future update.

Note that we are not including this component by default for items that override vanilla dyeable items, like leather armour, since on Java, dyeable items are defined through recipes. As such, we don't know whether a vanilla item could be dyeable when registering all custom items and creating their components. The vanilla item could've been removed from the vanilla dyeable recipe for example, thus, we have to rely on users putting this component in their mappings.

Also, please note that this PR also adds a @NonNegative annotation to CustomItemBedrockOptions#protectionValue, and appropriate checks for it. This is technically a breaking change - however, passing a negative protection value never was supported.

Reviews are welcome - personally, I feel like it may be wise to turn the dyeable key in the mappings into an object, to make it clearer what its value represents:

"bedrock_options": {
  "dyeable": {
    "default_color": "aceace"
  }
}

This is up for discussion though.

[onebeastchris]

Looks good, thanks for the PR! Just as a note - Bedrock seems to also support a default dyed icon for dyed items; do we need to set that?

[onebeastchris]

Personally, I'd make this a nullable Integer... or are we using OptionalInts anywhere these days?

[eclipseisoffline]

They are used in the now deprecated CustomItemOptions - personally, I really don't like nullable integers, they are very prone to NPEs as soon as they are casted to a primitive int.

[eclipseisoffline]

What are you referring to with "default dyed icon"?

[ezariago]

What are you referring to with "default dyed icon"?

I think he's referring to the this, not sure though I could be wrong

[eclipseisoffline]

Ah, I see, I was unaware. I will look into it.

[ezariago]

Wouldn't it be better to turn the dyeable key into an object? since it's more logical to modify dyeable object's color and icon in one place

"bedrock_options": {
  "dyeable": {
    "default_color": "aceace"
    "dyed_icon": "cloth:tshirt_dyed"
  }
}

I'll write a PR to @eclipseisoffline's fork for the dyed_icon implementation in a few min

[ezariago]

Sorry for the late reply, I've opened a PR in @eclipseisoffline's fork regarding the changes I made. I've tested it and everything works perfectly ⭐⭐

Screen_Recording_20260513_194146_Minecraft.mp4