fix: preserve CustomModelData when dropping MythicMobs items

[JrouleEnGolf5]

Problem

When a block drops an item configured with item: mythic:<id>, the
resulting ItemStack sometimes had no CustomModelData.

After generating the item via mythicItem.generateItemStack(amount),
the code was calling BukkitItemStack.setName() and BukkitItemStack.setLore()
on the MythicMobs wrapper. These calls reconstruct the ItemMeta internally,
wiping metadata set by MythicMobs during generation — including CustomModelData,
attribute modifiers, and other NBT data.

Additionally, the lore/name passed came from mythicItem.getLore() /
mythicItem.getDisplayName() — the raw config strings, before MythicMobs'
own rendering pipeline (color codes, MM placeholders, etc.).

Fix

Retrieve the Bukkit ItemStack directly from the generated result, then
apply BlockRegen's parser to the existing ItemMeta via the standard
Bukkit API. This preserves all metadata (including CustomModelData) while
still allowing BlockRegen placeholders in name and lore.

Reproduction

carrots:
  target-material: carrots[age=7]
  drop-item:
    item: mythic:my_mythic_item
    amount: 1

[Copilot]

Pull request overview

Fixes MythicMobs item drops losing generated metadata (e.g., CustomModelData) by avoiding MythicMobs wrapper setters that reconstruct/wipe ItemMeta and instead mutating the generated Bukkit ItemStack’s existing ItemMeta.

Changes:

• Retrieve the generated Bukkit ItemStack from MythicMobs and return it directly.
• Apply the BlockRegen parser to the already-rendered display name/lore via Bukkit ItemMeta (preserving existing metadata).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JrouleEnGolf5]

After a short beta test of the plugin, it turns out the issue still persists. I think I’ve found the cause, and I’ll update the pull request tonight.

[JrouleEnGolf5]

I tested with this version and it seems to have fixed the issue. Over to you ;)