Fix composite material regression from #71 and apply the fix to 26.1

[Pix3lPirat3]

Since 1.20.5 the tool component registers incorrect_for_wooden_tool as a material ahead of mineable/pickaxe, so every tier-gated block (108 on 26.1) reported it as its material. Its speed table only lists wooden tools, so prismarine-block digTime() falls back to hand speed: iron ore with a diamond pickaxe reports 4550ms instead of 600ms (PrismarineJS/minecraft-data#987, PrismarineJS/mineflayer#3921, PrismarineJS/mineflayer#4131). #71 fixed that by preferring the first mineable/* material. Regenerating with it shows a side effect: the filter also outranks every composite material (plant;mineable/axe, leaves;mineable/hoe, gourd;mineable/axe, vine_or_glow_lichen;plant;mineable/axe, sword_instantly_mines), which are the only materials carrying sword and shears speeds. That moves 23–66 blocks per version away from vanilla - on 1.21.11, bamboo with a sword goes from 200ms to 1500ms and vine with shears from 150ms to 300ms. It went unnoticed because no data has been regenerated since #71 merged. mc/26.1 was added by #70 from a pre-#71 copy and still returns the first match unconditionally.

Fix: skip incorrect_for_* instead of preferring mineable/*. Composites are registered first, so first-match order is preserved and only the drop-gating tags are excluded. Applied to the ten folders #71 touched and to 26.1.

Verification (regenerated all eleven folders, compared blocks.json field by field):

• vs shipped minecraft-data: the only material change is incorrect_for_wooden_tool -> mineable/pickaxe (60 on 1.20.5, 101 on 1.21/1.21.3, 93 on 1.21.5–1.21.8, 108 on 1.21.9+); no composite changes; materials.json unchanged.
• vs a 1.20.5-1.21 - Prioritize mineable material when multiple matches are found to fix problem of wrong dig time computation #71 regeneration: every composite restored.
• digTime() of the corrected output matches the vanilla formula for every changed block across all tool tiers and types on all eleven versions.
• Live on vanilla 26.1 with mineflayer 4.39.0: iron ore breaks in 607ms (was 4558ms); melon/leaves/vine sword and shears times unchanged.

#77 (26.2) carries the same pre-#71 code and needs the same lines. A minecraft-data update for 1.20.5–26.1 will follow from this output.

[VasilisDragon]

Regenerating against the merge base still loses some tool speeds:

• 1.20.5, 1.21 and 1.21.3 moss_carpet: mineable/hoe becomes plant; diamond-hoe speed drops from 8 to 1 and digTime() goes from 0 to 150 ms.
• 1.21.5 bamboo: mineable/axe becomes sword_instantly_mines; diamond-axe speed drops from 8 to 1 and digTime() goes from 200 to 1500 ms.

Vanilla's ItemStack.getDestroySpeed returns 8 for both pairs. I saw the bamboo composite issue noted in minecraft-data #1309, but this also loses working axe behavior from #71's generated output. Can we preserve the hoe/axe speeds while keeping the sword/shears behavior?

[Pix3lPirat3]

Thanks, both are real: those blocks match two materials with different speed tables and first-match keeps only one, whichever way the filter goes. Pushed a second commit that registers the two missing composites next to the existing plant;mineable/axe: plant;mineable/hoe (moss carpet, pink petals, and pale moss carpet on 1.21.3, i.e. blocks in sword_efficient and mineable/hoe) and, for 1.21.5+, sword_instantly_mines;mineable/axe (bamboo). The block then carries both tables, so the sword/shears rules and the hoe/axe speeds are both kept.

[Pix3lPirat3]

Both cases are fixed on the branch tip (13b448e added the plant;mineable/hoe and sword_instantly_mines;mineable/axe composites), so the regen that still lost speeds was against the merge base, before those composites existed.

Verified by regenerating the branch tip and checking the generated data:

• bamboo -> sword_instantly_mines;mineable/axe (1.21.5) / mineable/axe (1.20.5, 1.21.3), diamond_axe = 8
• moss_carpet -> mineable/hoe (1.21.5) / plant;mineable/hoe (1.20.5, 1.21.3), diamond_hoe = 8

Those match vanilla's ItemStack.getDestroySpeed of 8 for both pairs, and the committed data on the PR already carries them. Could you re-run against the branch tip rather than the merge base to confirm on your side?

[rom1504]

Astra agent review — AI-generated, not manually written by the maintainer.

The revised composites address the reported moss-carpet/hoe and bamboo/axe cases. I checked this exact head's CI-generated artifacts for 1.20.5, 1.21.3 and 26.1: every block material matches the candidate data in minecraft-data#1307. Production prismarine-block probes with that candidate data preserve the expected hoe/axe speeds and correct ore mining. The remaining 26.1 material-table differences are the copper/shears fixes already landed in data#1310 and supplied by generator#87/#88.

The code looks suitable to land once the incomplete CI checks are cleared. The failed 1.9.4 job is a Maven download read timeout, not a failure in these changed modules; 1.21.5/1.21.6 generation was cancelled. I used existing CI artifacts rather than rerunning a local Java server.

Skills used: prismarine-protocol-data-review followed generator output into the real block consumer and distinguished already-landed data from pending producer fixes; prismarine-architecture-review checked composite ordering and retention of both tool capabilities; prismarine-review verified the repaired feedback at the current head and diagnosed CI.