feat: reject equip-slot reward drops

Author: MikelCalvo

internal/minimal/shared_world_test.go

@@ -372,8 +372,9 @@ func TestSharedWorldRegistryRegisterGroundItemRejectsUnequippedItemWithEquipSlot
 		t.Fatal("expected equip-slot ground-item owner join to allocate a shared-world entity id")
 	}
 
-	if registry.RegisterGroundItem(ownerID, "equip-slot-ground-owner", owner, 0x07000014, inventory.ItemInstance{Vnum: 3001, Count: 1, EquipSlot: inventory.EquipmentSlotWeapon}) {
-		t.Fatal("expected unequipped ground item with equip slot metadata to fail closed")
+	item := inventory.ItemInstance{Vnum: 3001, Count: 1, EquipSlot: inventory.EquipmentSlotWeapon}
+	if registry.RegisterGroundItem(ownerID, "equip-slot-ground-owner", owner, 0x07000014, item) {
+		t.Fatal("expected unequipped ground item with equip-slot metadata to fail closed")
 	}
 	if registry.GroundItemExists(0x07000014) {
 		t.Fatal("expected rejected equip-slot ground item to stay absent")

spec/protocol/non-player-reward-bootstrap.md

@@ -61,6 +61,7 @@ Reward descriptors fail closed when:
 - a runtime-generated ground-item instance for a configured item-shaped drop would have `vnum = 0`
 - a runtime-generated ground-item instance for a configured item-shaped drop would have zero count
 - a runtime-generated ground-item instance for a configured item-shaped drop would exceed the current `GC ITEM_GET` count carrier (`255`)
+- a runtime-generated ground-item instance for a configured item-shaped drop would carry equipped/locked state or stale equipment-slot metadata
 - multiple drops in the same descriptor would collide on the generated ground-item VID
 - a configured drop would reuse an already-live ground-item VID