Update 779 unique item mod IDs

[kylande01]

Description of the problem being solved:

This updates 779 outdated unique item modifier IDs across 19 files in src/Export/Uniques using current live game data.

Each replacement was restricted to any case where:

• the unique name and current base type matched exactly
• the existing and candidate IDs resolved to the same complete stat-text tuple in ModItemExclusive.lua
• exactly one authoritative replacement candidate was available

There is a small handful of mod IDs that remain unchanged as they:

• have no matching unique item (these look like removed legacy items)
• have no matching modID in the json
• contain multiple modID lines, not matching the existing lua files in Export

These possible changes should be reviewed manually if it is deemed that they need to be updated.

Changes were updated using a patcher I put together in Python (screenshots below). The UI for the patcher was built by Codex because I hate doing UI stuff. This can be expanded to include any type of item ID if it's something you could see as useful. Adjustments can be made to update roll ranges on items, variants, or whatever else. It can also be used across both PoE1 and PoE2 game data, so anything we have a json for live data can be applied. If you're interested, I can submit a PR for the patcher or you should be able to check it out in my personal fork.

Steps taken to verify a working solution:

• Reanalyzed all 21 unique item export files after applying changes
• confirmed zero remaining safe replacement candidates
• confirmed that repeated analysis produces no further changes

Before screenshot:

After screenshot:

[mcagnion]

The first entry after Implicits: 1 is the Ruby Ring base implicit, but this replaces FireResistImplicitRing1 with the explicit unique mod ID that is already used again at line 308. The same collapse occurs for Circle of Fear (331/334), Nostalgia (383/386), and Regret (409/412). src/Data/Bases/ring.lua still identifies the four base implicits with the *ResistImplicitRing1 IDs, so equal stat text makes the tuple check pass while both distinct mods end up with one ID. Preserving the first implicit IDs and updating only the later explicit entries keeps the source identities distinct.

AI-assisted review disclosure: This finding was identified during a review using OpenAI Codex.

[kylande01]

Good catch. Not considering mutual implicit/explicit mod IDs groups is an oversight on my part. I'll do a full audit and make sure I haven't missed any more of these implicit mod collapses. A possible solution could be adding a ModGroup enumerator for IMPLICIT and EXPLICIT mod groupings for the loader to use. Let me take a second look and I'll post a refactor soon. Thanks.