Ensure uniqueness of sample nicks with nanoAOD version

[sofiagiappichini]

A fix was added to fold the NanoAOD version processing tag into the nick when the DAS name carries it (needed so that reprocessed versions of the same run/campaign don't collapse onto an identical nick). Most of the sample database predates that fix, so ~3,030 existing entries had a stored nick that no longer matched what the current code would generate from their dbs field (adding a version count at the end of the nick), while the biggest change is in Embedding and Data for Run2 that never specified the NanoAOD version and had duplicate nicks. This ensures no duplicated nicks are present and all samples can be run in one single call from KingMaker.

What this PR does: regenerates the nick for every entry where it doesn't match what _build_nick(dbs) currently produces, and renames the corresponding JSON file + updates the nick field + updates the matching key in that version's datasets.json cache to keep them in sync.

What was deliberately left untouched: 122 entries where regenerating the nick would have collided with another entry already using that name, or would have destroyed a hand-curated distinction the automatic derivation can't reconstruct from dbs alone — e.g.:

• _GT36-tagged reprocessings (different global tag, same otherwise)
• pre-existing _test/duplicate entries
• the 2025 MC campaign convention, where the nick intentionally says 2025 even though the dbs string says 2024Summer24, to keep it distinct from the real 2024 campaign
• existing _v2-v1-style reprocessing-version entries that already coexist correctly

All renames were verified: every renamed file's content (besides nick) is unchanged, datasets.json key counts match the pre-change count exactly for all three versions (no entries lost), and no filename or datasets.json-key collisions were introduced.