fix: decode painting variant item components

[milutinke]

What changed?

Models minecraft:painting/variant, including registry references and inline values. Container packets can now decode the painting and every slot after it instead of dropping the frame.

Versions affected

Minecraft 1.21.5 through 26.3, protocols 770 through 777.

Evidence

Vanilla encodes this component as a painting-variant registry holder. The direct form contains width, height, asset ID, optional title, and optional author. The original 26.3 reproduction dropped container_set_content at component wire ID 109. After this change, the painting and the following control item both survive reconnects on vanilla and Fabric 26.3.

Validation

• Focused painting-variant tests pass: 16/16.
• dotnet build UMPK.sln -c Release passes with no warnings.
• dotnet test UMPK.sln -c Release passes, and the test-count gate matches engineering/testcounts/expected_counts.json.
• dotnet format --verify-no-changes passes.
• Dataset verification passes for all 50 protocol datasets; language and generated-output checks are clean.
• Public API files and codec identity fixtures are current.
• Vanilla live tests pass for protocols 770 through 777; the Fabric 26.3 reconnect reproduction also passes.
• The full 50-version live matrix ran: 40 passed, while 10 legacy legs hit existing Java 17 memory or chest-assertion failures on protocols 107 through 340.
• The change contains no secrets, raw logs, Minecraft artifacts, or unrelated changes.

Notes for reviewers

This adds PaintingVariantComponent, PaintingVariantDetails, and DataComponents.PaintingVariant to the public API. Codec identity hashes change for protocols 770 through 777 because their item-component tables now include the modeled codec.