[PowerDisplay] Add stable profile IDs

[moooyo]

Summary of the Pull Request

Gives every saved PowerDisplay profile a stable, auto-incrementing integer id and makes the app address profiles by that id instead of by name. Duplicate profile names are now allowed (the id disambiguates them) and renames are non-lossy for anything that references a profile.

Split out of the PowerDisplay CLI branch (#48632) so it can be reviewed and merged against main on its own. The CLI-specific apply-profile-by-id integration (the PowerToys.PowerDisplay.Cli project, contracts, and app-side IPC handlers) is not part of this PR — it stays with #48632, which builds on top of this work.

PR Checklist

• Closes: #xxx
• Communication: I've discussed this with core contributors already.
• Tests: Added/updated and passing — PowerDisplayProfilesTests (id math / EnsureIds / DisplayName), LightSwitchProfileIdTests (settings id round-trip + Clone preserves ids), and LightSwitchProfileResolverTests (id-first resolution / stale-id no-fallback / name→id migration) in PowerDisplay.Lib.UnitTests.
• Localization: No new end-user strings (the #id suffix is a formatted label, not a resource).
• New binaries: None.
• Documentation updated: Not required.

Detailed Description of the Pull Request / Additional comments

Model (PowerDisplay.Models)

• PowerDisplayProfile.Id — JSON id, int, 0 = unassigned; plus DisplayName ("{Name} (#{Id})", [JsonIgnore], UI only).
• PowerDisplayProfiles.NextId — JSON nextId, a monotonic counter that only ever increases and is never reused.
• SetProfile is id-keyed: a profile with Id == 0 is assigned the next id; an existing id replaces in place (so a rename keeps the same id). Names are not required to be unique.
• GetById, RemoveProfile(int) / ProfileHelper.RemoveProfileById, and an idempotent EnsureIds() that back-fills ids for legacy profiles and self-heals nextId past the highest id in use.
• ProfileHelper.LoadProfilesEnsuringIds() loads then back-fills ids atomically (single lock). The now-dead name-based RemoveProfile(string) overloads (helper + container) were removed — deletes are id-keyed.

App (PowerToys.PowerDisplay)

• Startup migration BackfillProfileIds() runs inside the existing legacy-monitor-id side-file migration (before its no-monitor early return) so an existing profiles.json is upgraded in place with no data loss, then migrates the LightSwitch mapping from name to id.
• ApplyProfileByIdAsync(int); the ApplyProfile Named Pipe message now carries the id (parsed with int.TryParse).
• LightSwitchProfileResolver (see below) resolves id-first, and does not fall back to a stale/deleted id (so a removed profile can't be silently replaced by a same-named different one), plus a one-shot name→id migration.

Settings UI

• Apply / edit / delete profiles by id (edit reuses the id, so renames are in-place); the profile editor round-trips the id.
• LightSwitch stores both *ProfileId and the name and selects the current item by id via the shared LightSwitchProfileResolver (SelectByStoredReference); LightSwitchSettings.Clone() now copies the id fields (previously they were dropped, which would reset the stored ids on the next settings save).
• Lists and pickers bind DisplayName, so duplicate names are distinguishable in the UI.

Cleanup (follow-up commits)

• Moved LightSwitchProfileResolver into Settings.UI.Library so the app (LightSwitchService) and the Settings UI (SelectByStoredReference) share one id-first / name-fallback implementation (Resolve + HasReference), removing a duplicated decision and the hard-coded "(None)" sentinel that previously lived on both sides.

• LoadProfilesEnsuringIds() collapses the repeated load → EnsureIds → save in the two Settings UI load paths into a single atomic call (also closing the previous two-lock race window between load and save).

• Simplified EnsureIds() (Math.Max + LINQ, behavior-preserving) and removed the dead name-based remove overloads described above.

• PowerDisplayViewModel: CreateProfile/UpdateProfile collapsed into one private UpsertProfile (they became identical once UpdateProfile moved to the id-keyed AddOrUpdateProfile).

• LightSwitchViewModel: extracted SetSelectedProfile(...) to drop the symmetric dark/light selection-setter duplication, and removed the now-unused legacy DarkModeProfile/LightModeProfile string VM properties (no bindings) plus their notifications.

• App MainViewModel.Settings: extracted LoadValidProfileById() shared by ApplyProfileByIdAsync and the LightSwitch apply path.

Validation Steps Performed

• Built the affected projects clean (x64/Debug, VS MSBuild, exit 0): PowerDisplay.Models / PowerDisplay.Lib, PowerToys.PowerDisplay (app), Settings.UI.Library, PowerToys.Settings (Settings UI), and PowerDisplay.Lib.UnitTests.
• PowerDisplay.Lib.UnitTests: full suite green (156/156), including 17 profile-id tests — 8 model (PowerDisplayProfilesTests), 2 LightSwitch settings (LightSwitchProfileIdTests), and 7 resolver (LightSwitchProfileResolverTests).

[moooyo]

Cross-reference: split out of #48632

This PR is split out of #48632 — [PowerDisplay] Add headless CLI and stable profile IDs, which contains both the PowerDisplay headless CLI and this profile-id feature.

• [PowerDisplay] Add stable profile IDs #49175 (this PR) carries only the non-CLI profile-id changes (models, startup migration + LightSwitchProfileResolver, Settings UI, LightSwitch), targeting main so it can be reviewed and merged independently.
• The CLI-specific apply-profile-by-id integration — the PowerToys.PowerDisplay.Cli project, PowerDisplay.Contracts, and the app-side Ipc/ handlers — stays in [PowerDisplay] Add headless CLI and stable profile IDs (PowerToys.PowerDisplay.Cli) #48632, which stacks on top of this work. (The CLI-only MainViewModel.ApplyProfileForCliAsync helper is intentionally omitted here for the same reason.)

Merge relationship: if this PR merges first, #48632 will be rebased onto main to add only the CLI layer on top; if #48632 merges first, this PR becomes redundant.