Fix mission key duplicator pickup-and-right-click interaction in PRK.Client

Goal: Make mission key duplicator item 28564 work in PRK.Client by picking it up on the cursor and right-clicking a mission key, without Shift or the tradeskill kit. Implementation is underway. Preserve the existing server duplication protocol and reusable inputs; validate client interaction and authoritative delivery before changing server behavior. Repository evidence: - Local GameData/rdb/cd_image/rdb.db, rdb_1000020 records 28564 and 28577: entity types MissionKeyDuplicator (51054) and MissionKey (51053). Item 28564's description explicitly says to pick it up and right-click the mission key, and that keys can be given to friends/team members without requiring team membership. Its can stat is 9 (Carry | Use), not a tradeskill recipe or consumable flag. - PRK.Client/PRK.Client/UI/ItemInteractionController.cs currently handles carried-item Shift-right-click through Combine, restricted to main inventory; plain right-click instead activates the target. - CharacterInterface.CombineItems and ClientTradeskillState.Combine send CharacterActionType.UseItemOnItem, which invokes tradeskills server-side. Do not reuse that packet for duplication. - AOEmu.PlayfieldEngine/Handlers/GenericCmdMessageHandler.cs already implements duplication for GenericCmdAction.UseItemOnItem (5), targets [source container-slot identity, target container-slot identity]. It accepts Inventory/Backpack locations and either item order, validates exact types/templates (28564 + 28577), links a newly allocated key to the active mission record, acknowledges the command and delivers the item through GiveItem plus SIFU. It retains the original key and duplicator. It rejects completed/unlinked missions. - ClientItemUse already centralizes GenericCmd construction, references and slot encoding for world-object item use; extend it for inventory item-on-item use. Existing inventory update handlers should own delivered-key state. Its Apply handles ordinary Use acknowledgements only; do not introduce optimistic duplication or generic consumption on the new acknowledgement. Implementation inspection also found that incoming SimpleItemFullUpdate inventory deliveries were only processed by the trade ledger. Extend ClientInventoryState's existing creation queue/delivery/settlement flow for temporary simple-item deliveries and wire it into N3MessageHandlerTable. Purchased duplicators may still have Identity.None locally. User reproduction logs additionally confirm both 28564 and 28577 can arrive as InstancedItem with real instance IDs; template eligibility must accept those generic identities. Incoming key full updates must settle and normalize an existing generic instance only when its instance ID and low/high templates match. The prior type-only guard rejected the user's correct right-click before sending any packet. Fixed the guard to accept InstancedItem for exact templates and added instance/template-matched normalization during authoritative settlement. Focused validation passes: 248 client interaction/inventory/trade/item-use regressions, including the generic-identity reproduction; local RDB metadata validation passed separately. User confirmed the corrected right-click duplication works live. Temporary diagnostics have been removed at the user's request; cleanup build passes with zero warnings/errors. Overflow and the remaining mission validation (traded/copied keys, reconnect persistence and entrance access) remain unchecked. Temporary [items.use-on-item] diagnostics identified the mismatch and have now been removed after user confirmation. Do not add left-click duplication or tests solely for diagnostics. Scope/approach: 1. Confirm the item metadata and exact request/response contract in focused fixtures, including delivery/mission-key identity handling; treat current server behavior as implementation evidence, not an independently verified retail packet capture. 2. Add a distinct carried-item right-click route using existing interaction resolution, fresh bindings, placement-pending guards and ClientItemUse command construction. Keep the eligibility decision centralized, separate from normal tradeskill combining. Support owned inventory/open bags using existing location encoding; reject bank, loot, equipment, stale and self targets. Preserve existing Shift-right-click tradeskills and modifier-based trade offers. 3. Reuse authoritative inventory delivery/update paths and verify cursor behavior, retained inputs and exactly one new key per accepted operation. Make only directly necessary server corrections if the end-to-end check demonstrates a gap; no new recipe system or broad inventory refactor. Acceptance criteria: - Picking up 28564 and right-clicking 28577 without Shift sends GenericCmd UseItemOnItem with correct source/target locations, local user/identity and command reference, not CharacterAction tradeskill or ordinary target Use. - A successful server operation yields one distinct key linked to the same mission with matching quality; original key and reusable duplicator remain. Existing server-supported reverse order remains compatible where exposed by the interaction policy. - Delivery is reflected once via authoritative inventory messages, including overflow when full; no local phantom key, input loss or accidental consumption. - Invalid targets, pending/stale slots and completed/unlinked missions cannot mutate inventory or trigger unrelated use/tradeskill fallback for a claimed duplication click. - Main-inventory and open-bag locations work; bank/loot/equipment are excluded. Ordinary item use, Shift-right-click tradeskills, trade offers, stack operations and item-on-world-object use remain unchanged. - Focused automated regressions and a live client/server smoke test pass, including traded/duplicated keys, reconnect persistence and mission entrance access. Validation: Extend ItemInteractionTests, item-use and existing packet/inventory fixtures; add focused server regression coverage only where needed. Run relevant client/server test projects and builds, then a live smoke test. No major refactor expected. Known acceptance gap discovered during implementation: PRK.Client has no overflow inventory state/view. With a full main inventory the server stores the new key in overflow and sends BaseInventoryUpdate, which the current client cannot display. Keep the overflow acceptance criterion and final validation outcome open; do not claim this is verified by the no-phantom/full-inventory regression. Adding a general overflow UI is a separate scope decision. Live validation also needs a test character with an active mission and both items. Pull request: #2689 — https://git.project-rk.com/prk/engines/pulls/2689 (fix/mission-key-duplication-and-names → develop). Includes client fixes in 97f307459 and server key naming/persistence fixes in 0653de02a.