fix(dmm-import): stop treating unknown mods as already managed

[Slush97]

Problem

The DMM import that runs as the first step of Fix Unknown has quietly done almost nothing since #296 (2026-07-24) on the default DMM setup, where DMM shares citadel/addons with Grimoire.

• Startup (backfillMissingMetadataHashes) gives every unknown VPK a metadata row with its sha256, and enrich adds globalType and, for hero skins, an inferred lockerHero.
• migrateDmmInstall put every row with a sha256 into managedHashes, so DMM's own files were skipped as "an identical file is already managed by Grimoire".
• isGrimoireManaged counted any lockerHero, so hero skins would be refused even once the hash check was fixed.

Fix

• hasModIdentity(meta) in metadata.ts: a row counts as managed only if it has a GameBanana id, a name, a Grimoire-built VPK (merged, Locker builds, soul/urn imports, sound swaps, forge installs) or a user choice (manual hero, local variant group, priority mod). Hashes and inferred hero/global type do not count.
• dmmMigration.ts uses it for the "already managed" hash set and for the in-place ownership check (replacing isGrimoireManaged).
• When DMM's file sits outside Grimoire's folders but Grimoire already lists the same bytes as an unknown mod, that file is tagged instead of copying a second one (keeps the old "no duplicate copies" behavior).

@grimoire/social-types, IPC and i18n are untouched.

Testing

• 3 new guard tests (dmmMigration.guards.test.ts) seed the rows startup actually writes. Two of them fail on main; the manual-hero one checks protection is kept.
• tsc -b, eslint, vitest (2651 passed), ui:check, i18n check and manifest check all pass.
• Real data: a DMM library built by DMM main (b626d504) through its real UI with 7 real GameBanana mods (hero skin, particle skin, sound, HUD, multi-file, disabled, downloaded-only), reshaped to DMM 1.1.0's on-disk format, imported through dmm-migrate:scan/execute in a throwaway Grimoire:
  • main: 1 adopted, 6 skipped, 6 left unknown.
  • this branch: 7 adopted with the right identity (bytes match DMM's records), hero skins included, 0 unknown left; a second run adopts nothing and changes no files.

Known, not changed here

DMM 2.0 parks a downloaded-but-never-enabled mod as <id>_<name>_dir.vpk in the addons root. This import copies it to .disabled (never moving DMM files), and Grimoire's scan then drops the identical .disabled copy, so the root file ends up identified but listed as enabled. Same behavior as before #296; #417's importer handles this case by moving the file.

Related: #417 replaces this flow with the interchange importer and has the same two checks in importer.ts; it should reuse hasModIdentity after rebasing.

[Skeptic-systems]

@Slush97 Should be fixed now, worked fine in my tests.