Name custom (Nexo) items in memos + market records

[ParadauxIO]

The Treasury transaction memo and the market sale/shop records named items from the raw vanilla material — TreasuryListener used the sign's item line, and MarketRecords used the non-event MaterialUtil.getSignName + ItemMeta. For a custom item (e.g. Nexo) that loses the real identity: it records the base material, not the custom id.

Fix

Route item naming through ChestShop's own event-backed ItemUtil.getName(item, 0). That fires ItemStringQueryEvent — the same seam the server's custom-item bridge (Nexo / ItemBridge) hooks to name and parse its items — so a custom item resolves to its provider code. When no provider claims the item, ItemUtil falls back to the vanilla code, so vanilla behaviour is unchanged. No Nexo dependency is added to ChestShop (load-bearing rule 6).

• MarketRecords — itemKey/itemName/isCustom go through ItemUtil with a vanilla fallback; isCustom now flags an item a provider named beyond the plain code; a custom item with no display name reads as its provider id rather than the base material.
• TreasuryListener.buildTransferMessage — the memo names the traded stack via ItemUtil, falling back to the sign item line (so it's never worse than before).

Verification

Built (mvn package) and deployed to the dev server; all 17 ChestShop integration tests pass — including ChestShopSalesTrackerE2ETest, which asserts the chestshop_sale/chestshop_shop rows produced by the changed naming path. The custom-item integration test (NexoCustomItemShopTest, added in the integration-tests repo) skips cleanly on a server without Nexo.

Vendored upstream fork — change kept to ChestShop's own idioms (ItemUtil / ItemStringQueryEvent).

🤖 Generated with Claude Code

[github-actions]

Coverage report

Overall Project	24.1% -0.92%	✅
Files changed	0%	❌

File	Coverage
MarketRecords.java	0% -25.15%	❌