Resolve item component updates and remaining durability

[Pix3lPirat3]

On Java 1.20.5+, component setters can update the map without updating the array used for serialization, and damage updates can leave the previous component value in place. This introduces shared internal component handling so edits, removals, and serialization use the same state.

Durability and stack-size properties resolve overrides against the registry's defaults. remainingDurability uses those resolved values rather than inspecting protocol removal fields itself. Removals use the protocol's { type } objects; the original string-only fixture did not cover real decoded removals.

Existing mutable component arrays and common Map operations remain supported. Editing an item no longer changes the decoded packet's component-entry arrays. Name, lore, repair-cost and damage setters serialize their changes; setting name, lore, or damage to null removes that component. item.nbt keeps aliasing the custom_data component as merged in #185.

Validation:

• Component and ordinary Slot codec checks on 1.20.5, 1.20.6, 1.21.1, 1.21.4, 1.21.5, 1.21.11 and 26.1, including overrides and object-shaped removals.
• Every item's default durability compared with official server-generated reports for those seven versions: 9,785 item entries, zero mismatches with the companion data correction for 1.20.5/1.20.6.
• Live vanilla 1.20.6, 1.21.11 and 26.1 accepted edited damage, name, lore and repair cost, and retained explicit removal of damage/max_damage.

Accurate default durability on 1.20.5/1.20.6 needs the companion data correction, PrismarineJS/minecraft-data#1288, to reach the installed minecraft-data package.

The live harness uses minecraft-protocol to encode the component ByteArrays required by creative inventory's UntrustedSlot on 1.21.5+. This PR does not add that packet-specific conversion to Item.toNotch or fix Mineflayer's creative packet caller; Item.toNotch continues to return ordinary decoded Slot data.

[extremeheat]

I think asking Astra/Fable to properly implement item components would be best

The removedComponents check (and fact that it's stored at all as member of the class) doesn't make sense when it's for protocol level state updates

[Pix3lPirat3]

The second commit is that implementation. lib/components.js holds one ItemComponents state per item; components, removedComponents, componentMap, maxDurability and stackSize are now accessors over it rather than separately stored fields, defaults resolve from the registry, and toNotch serializes by filtering the shared state.
removedComponents is kept on the surface only for API compatibility - it's derived, not stored; can drop it if you'd rather. Title and description updated to match; rebased on master over #185.

[rom1504]

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

The revised shared component state addresses the mutation/serialization split I checked: all 266 tests pass, and additional production compiled Slot probes preserve edited damage, name, lore, repair cost and explicit removals on 1.20.5, 1.20.6, 1.21.1, 1.21.4, 1.21.5, 1.21.11 and 26.1. The compatibility array/Map surfaces feed the same serialization state; I found no new blocker in these paths. Accurate default durability on 1.20.5/1.20.6 still requires the already-linked data #1288 to reach the installed package. No live vanilla server was run in this pass, and ordinary Slot coverage does not claim UntrustedSlot creative-packet support.

Skills used: prismarine-item-inventory-review traced setter/removal → shared state → serialization and checked versioned defaults; prismarine-architecture-review checked the model owns that state while retaining the public compatibility surfaces; prismarine-protocol-data-review exercised real compiled Slot codecs; prismarine-review checked the later implementation against the original maintainer feedback.

[rom1504]

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

Rechecked 0a28aba and the existing discussion.

The previous exact-head component review remains applicable: the shared state addresses the checked mutation/serialization split. I found no additional defect to duplicate. Before landing, resolve the current merge conflict and rerun the component/Slot checks on the result; accurate older-version defaults also retain the previously documented data #1288 release prerequisite.

The 266-test and seven-version codec results are carried from that review, not newly rerun here.

Skills used: prismarine-item-inventory-review checked the item component/state contract; prismarine-protocol-data-review checked version selection and candidate-versus-release readiness; prismarine-architecture-review checked package boundaries and public compatibility; prismarine-review checked current scope and existing feedback to avoid duplicate threads.

[Pix3lPirat3]

Rebased onto current master. The conflict was in index.js, in the customName and customLore getters, because master's #189 landed after this branch and changed those getters to return the chat-component JSON string, while this branch had routed component access through the new componentStates/ItemComponents state. I reconciled the two: component access still goes through componentStates, and the resolved value is passed through #189's chatComponentJson so both the component value (1.20.5+) and the legacy display.Name/display.Lore fallback read back as the same JSON-string shape index.d.ts promises. chatComponentJson is identity on an existing string, so the fallback path is unchanged.

One test in component mutations survive serialization had to follow the #189 shape: the wire still carries the raw component (that assertion is unchanged), but the read-back of customName/customLore is now the JSON-string form, so I set the per-property expected read-back accordingly (repair_cost/damage stay raw). Round-trip integrity is still asserted.

Verified: full suite 271 passing / 0 failing (all component, durability, fixture, anvil and basic checks across the 7 component versions), lint clean on the changed files.

[rom1504]

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

Reviewed updated head 0c4cca354142. The rebase correctly composes the shared component state with #189's JSON-string getter contract. The delta from the previously reviewed head changes name/lore normalization and their read-back assertions while retaining raw component payloads for serialization; literal JSON-looking NBT strings remain literal after decoding.

I ran the full candidate suite: 271 passing. Package self-imports explicitly resolved to this candidate. I also reran actual compiled NMP set_slot round trips on 1.20.5, 1.20.6, 1.21.1, 1.21.4, 1.21.5, 1.21.11 and 26.1: edited damage/name/lore/repair-cost values and explicit removals survived all seven versions. Dependencies were minecraft-data 3.117.0 / minecraft-protocol 1.68.0 / ProtoDef 1.19.0. No new code blocker found, and current CI is green.

The existing release prerequisite remains: data #1288 is still open, so accurate 1.20.5/1.20.6 registry durability defaults require that correction to ship. This is a good candidate for coordinated maintainer review of the shared component model plus its data correction; do not read the passing ordinary-Slot probes as UntrustedSlot creative-packet support or a new vanilla-server validation. No duplicate inline finding.

Skills used: prismarine-review compared current discussions and the exact rebase delta; prismarine-item-inventory-review followed edits/removals through the common state and serialization; prismarine-protocol-data-review checked real compiled codecs and the released-data prerequisite; prismarine-architecture-review checked that model state stays in the reusable item package.