EquipmentAttachableGenerator

Emits a worn-armor Bedrock minecraft:attachable that overrides the rendered armor texture on the player body. Called from the items pipeline (per (item × base item) mapping) so the attachable lives at the SAME bedrock_identifier that Geyser will route to from the Java minecraft:item_model predicate.

Why driven from the items pipeline (not from equipment/*.json): Geyser's custom-item-v2 "model" field matches against the Java item's minecraft:item_model component — NOT the equippable.asset_id. If we keyed our mappings on the equipment identifier, Geyser would never route worn iron/etc. armor through them. Rainbow itself does this the same way: see BedrockAttachableContext.java:43-62 — for armor, Rainbow uses equippable.assetId() ONLY to look up EquipmentClientInfo.getLayers(...) for the texture path; the attachable identifier comes from the item_model-derived bedrock identifier.

Reference implementation — mirrors Rainbow's BedrockAttachable.equipment(...) static builder (rainbow/src/main/java/org/geysermc/rainbow/pack/attachable/BedrockAttachable.java lines 42-69) for the attachable shape itself.

The emitted attachable's geometry references Bedrock-shipped vanilla armor geometries by identifier (e.g. geometry.player.armor.helmet) — these are baked into Bedrock's vanilla resource pack and don't need to be redeclared. The scripts.parent_setup field emits the per-slot Molang that hides the corresponding vanilla armor layer so the custom and vanilla armor don't double-render.