feat(plugin-api): add item stack persistent data container v1

[CompileRider]

Problem

Pumpkin plugins currently have no persistent data container support. Issue #635 asks for broad owner coverage, but the current plugin/WASM surface only cleanly exposes ItemStack as a first real public owner.

This PR ships the first usable slice instead of a foundation-only refactor:

• additive v0.2.0
• Foundation + ItemStack only
• no Entity owner yet
• no typed PDC helpers yet

What changed

• pumpkin-data/src/item_stack/mod.rs: adds ItemStack-owned plugin PDC storage and NBT round-trip persistence under pumpkin:plugin_data
• pumpkin-plugin-wit/v0.2.0/*: adds the additive v0.2.0 guest surface plus the new item-stack resource and PDC methods
• pumpkin-plugin-api/{Cargo.toml,src/lib.rs}: moves the guest crate onto the new versioned surface
• pumpkin/src/plugin/loader/wasm/wasm_host/*: adds v0.2.0 host/version dispatch and the ItemStack resource backing
• Cargo.lock: refreshes the workspace lockfile used by this branch

Testing

• cargo fmt --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test -p pumpkin-data pdc_ -- --nocapture
• cargo test -p pumpkin-data item_stack_serialization_round_trips_plugin_data -- --nocapture
• cargo test -p pumpkin item_stack_resource_mutates_real_owner --no-run
• Direct execution of the compiled item_stack_resource_mutates_real_owner test binary
• cargo audit, lol

Scope

• keeps v0.1.0 working
• adds additive v0.2.0
• keeps the first PR limited to ItemStack
• leaves Entity and the broader owner matrix for later work

Part of #635

[CompileRider]

Switching this back to draft for now. After revisiting the implementation, I think there’s a better way to structure parts of this PR, so I want to clean that up before putting it up for full review.

[CompileRider]

This is a disaster, time for coffee

[illyrius666]

~6k lines are going to be a hell to review in one pr, wouldnt it be better to split this up into multiple pr's?

[CompileRider]

That was a fair concern for the earlier ~6k-line version, and I agreed with it there.

After the reduction, I don’t think splitting it further would help much. The remaining size is mostly the additive v0.2.0 access path needed to expose ItemStack as a real first owner, and splitting now would mostly turn this into an infrastructure-first PR plus a dependent feature PR.

So I’m keeping it as one draft PR and focusing on making the remaining shape easier to review.

[CompileRider]

I did one more structural reduction pass before taking this out of draft.

The main remaining weakness in the reduced branch was that v0_2_0/player.rs was still carrying a large manual copy of the player host implementation, even though the actual v0.2.0 delta for this lane is very small.

That has now been refactored so the shared player host logic lives in wit/player_shared.rs, while the versioned wrappers stay thin:

• v0_1_0/player.rs is now just the v0.1.0 wrapper
• v0_2_0/player.rs is now just the v0.2.0 wrapper plus the two ItemStack resource accessors required for this PR

So although the total diff vs origin/master changed numerically, the structure is much better now:

• the duplicated player host implementation is gone
• the versioned player.rs files are no longer broad manual copies
• the remaining v0.2.0 code now reads like a real delta for the ItemStack PDC slice instead of a second full player host implementation

At this point, the remaining heaviness is mostly the shared implementation itself and the versioned API surface, not duplicated wrapper churn.

[Snowiiii]

There will be no v0.2.0 since there isn't even an official v0.1 release

[CompileRider]

There will be no v0.2.0 since there isn't even an official v0.1 release

I understand