Fix bedrock digTime: harvestTools ids + materials table

[Pix3lPirat3]

Problem

Bedrock block.digTime() returns hand-breaking time for every tool-mineable block (1.26.0-1.26.30), so tool tier and Efficiency never apply. For example bedrock stone with a diamond pickaxe reports 7500ms (hand) instead of ~300ms.

Root cause: three data bugs, all from copying pc data into bedrock without remapping to the bedrock id space:

1. blocks.json harvestTools lists pc (Java) tool item ids that don't exist in bedrock items.json (e.g. stone: {941,946,...} while the bedrock pickaxes are 341/345/328/356/349/648/775).
2. dataPaths points bedrock materials at pc/1.17, whose speed table is keyed by pc tool ids.
3. Many pickaxe blocks (ores, obsidian, ...) are tagged incorrect_for_wooden_tool, which has no speed table.

Fix

• tools/fixBedrockHarvestTools.cjs remaps harvestTools to bedrock item ids (a self-contained, format-preserving text edit: the reference block that lists all seven pickaxes gives the tier order) and retags incorrect_for_wooden_tool pickaxe blocks to mineable/pickaxe.
• tools/genBedrockMaterials.cjs generates a per-version bedrock materials.json from pc/1.17 by tool name (adding the bedrock-only copper tools), and dataPaths is repointed to it.

Verification

Via prismarine-block on bedrock_1.26.45: stone/diamond_pickaxe 7500 -> 300ms (+Efficiency V 100ms), obsidian/diamond 9400ms, iron_ore/diamond 600ms - all vanilla-correct; Efficiency now applies. Also confirmed with a live mineflayer-bedrock bot's bot.digTime.

Companion to the pc-side digTime material work (#1307 / generator #86).

[rom1504]

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

Reviewed 021d680: the committed block remapping reproduces exactly from the base files, and all eight changed block/material files pass their schemas. The new material tables reproduce exactly and all their IDs resolve to Bedrock items. Using the actual prismarine-block consumer, I reproduced the stated stone/diamond 300ms (100ms with Efficiency V), iron-ore/diamond 600ms and obsidian/diamond 9400ms figures. Those are consumer checks, not an independent BDS timing measurement.

The inline finding concerns the new repair tool: rerunning it on the committed data corrupts tool tiers, and its pickaxe-only assumption leaves 22 non-pickaxe harvest references unresolved per version.

Skills used: prismarine-protocol-data-review checked source reproduction, edition-specific IDs and generated references; prismarine-architecture-review checked whether the producer remains safe to run; prismarine-world-render-review traced those facts through the real block model.

[rom1504]

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

Please make the source ID namespace explicit or reject already-remapped input before constructing this map. Running the documented tool on this PR’s committed data/bedrock/1.26.30 treats the sorted Bedrock IDs as Java tier order and silently changes 117 harvest-tool records. For example, obsidian changes from {349,648} (diamond/netherite) to {349,356} (diamond/gold); the real block consumer then accepts a golden pickaxe and rejects netherite. Diamond ore also starts accepting a wooden pickaxe. A second run must preserve correct data or fail without writing.

The assumption that every harvest-tool entry is a pickaxe is also false: the tool reports 22 unmapped references in each of the four versions, covering web, snow_layer and snow. On the committed data, canHarvest(diamond_shovel) is still false for snow because those IDs remain in the other edition’s namespace. Mapping from a specified source item table by name, validating all references, and guarding already-converted input would address both failure modes.

Skills used: prismarine-protocol-data-review checked original-input reproduction, rerun behavior and item-ID references; prismarine-architecture-review checked producer safety; prismarine-world-render-review verified the resulting canHarvest/digTime behavior.