Preserve mission key names in client display and server persistence

Goal: Display the server-provided mission key name (for example Mission Key to a house), rather than the base RDB name Mission Key to. Client interaction and display fixes are committed as 97f307459. Server naming/persistence changes are committed as 0653de02a on fix/mission-key-duplication-and-names. Evidence: server BuildSIFU emits item.NameOverride in SimpleItemFullUpdateMessage.Name, and mission creation/team sharing assign Mission Key to {EntranceName}. ClientInventoryState's temporary simple-item delivery/settlement path currently drops Name. InventoryItemPresentationProvider always resolves/caches names by low/high template and quality, so per-instance names must be applied after cache lookup, not inserted into the shared template cache. Scope: retain optional instance names from authoritative simple-item updates; propagate through existing inventory moves/delivery/trade settlement; use them in inventory/table/tooltip and instance inspection while template-only links retain the base RDB name. Keep server authority and template fallback for empty names, avoid names leaking between keys with identical templates, and do not add diagnostics or alter duplication gestures. Follow through on the confirmed server-side duplicate-name defect: immediate duplicate naming, consistent canonical/player mission key registration and dirty tracking, and recovery of previously created unnamed copies on login. Acceptance: named key updates survive generic-instance normalization and temporary delivery; two same-template keys can show different server names; unnamed/template-only items retain RDB fallback; ordinary inventory operations and trade settlement do not discard the name. Verified: client build and 282 focused regressions pass (instance names, wire delivery/normalization, inventory moves, trade handover/settlement, presentation cache isolation/fallback, inspection, existing duplication and item-use behavior). No diagnostics were added. Live capture now establishes the client/server boundary: first character received two keys named Mission Key to a house; replay through the actual handler and presentation provider retains/displays both names. Second character received three key SIFUs: instance 683781 (slot 75, QL54) named Mission Key to A building in Borealis; instance 1457140 (slot83) named Mission Key to a ruined building; instance1454955 (slot84) explicitly carries a zero-length Name. User sees a named and unnamed key accordingly. The remaining blank-name issue is server-side: instance1454955 is registered in active pc_missions QuestId200583898 (entrance a house), but absent from the saved pc_extended mission identities used by NewPlayerCharacterRepository to reconstruct NameOverride on login. Code investigation confirms three defects: (1) GenericCmdMessageHandler duplicate creation never assigns newKey.NameOverride, unlike both normal creation paths and team sharing; (2) it appends only to the separately loaded pc_missions QuestInfo, not the player's MissionQuest.Info; (3) MissionQuest.PersistedStateHash excludes QuestIdentities and EntranceName, so merely mutating those fields/queueing a save would still not guarantee pc_extended persistence. NewPlayerCharacterRepository reconstructs names only from pc_extended mission keys and explicitly does not persist per-item NameOverride. The existing copy is therefore reachable through canonical mission validation but unnamed after login. Server fix implemented: shared MissionKeyService handles immediate copy naming, idempotent canonical/player registration, and load-time recovery through registered mission records and entrance metadata. Player registration waits for canonical save success; shared-list state is rolled back on failure. Normal logins use saved mission metadata first and only query canonical records for unresolved keys. The canonical lookup is parameterized SQL JSON filtering, not full record materialization. Mission dirty tracking now includes entrance names and order-independent key registrations. Verified: 89 focused server tests pass, including red-green dirty tracking, copy naming/registration, old-copy and traded-key recovery, save-failure rollback and existing character/extension persistence regressions. A read-only harness ran the actual SQL lookup and recovery against the captured broken key: it was absent from the saved mission, recovered as Mission Key to a house, and was added to the in-memory mission registry without database writes. Static review finding about failed-save phantom registrations was fixed with regression coverage. No diagnostics or schema migration were added. Remaining validation: the running local playfield process still has its old binary; no service restart/deployment was performed. Rebuild/restart the playfield engine and relog to confirm the corrected name in a fresh live packet before closing the final live-verification item. Pull request: #2689 — https://git.project-rk.com/prk/engines/pulls/2689 (fix/mission-key-duplication-and-names → develop).