fix: serialize Gaming Profile crash-recovery on the service gate

[laurentiu021]

Problem (P2 — startup race, non-destructive but user-visible)

On launch, if a previous run closed/crashed with game-mode tweaks still applied, the Gaming Profile tab offers to revert them via GamingProfileService.RecoverPendingAsync. Unlike ApplyAsync and RevertAsync — which both serialize on the service's SemaphoreSlim (_gate) — RecoverPendingAsync ran its RunRevertAsync and its LoadStore→SaveStore completely ungated.

After the user answers the "restore leftover changes?" dialog, the UI is live again. Clicking Start then launches ApplyAsync concurrently with the still-running recovery revert:

• Two paths reverting/applying the same machine-wide tweaks (power plan, visual effects, search indexing, notifications) at once.
• An unsynchronized read-modify-write of the on-disk store: recovery's LoadStore … SaveStore(store with { ActiveSession = null }) can interleave with Apply's SaveStore(… with { ActiveSession = <new> }), losing one write. If the ActiveSession = null clear is the one lost, the leftover marker resurrects and the app re-prompts for recovery on every launch.

Fix

RecoverPendingAsync now acquires _gate for its whole body, mirroring RevertAsync:

• Serializes against ApplyAsync / RevertAsync (a concurrent Start now waits for recovery to finish, and vice-versa).
• Re-reads the store inside the gate so the read-modify-write is atomic against a concurrent SaveStore.
• Uses ConfigureAwait(false) under the gate for the same anti-deadlock reason the other two do (the gate-release continuation must stay off the UI thread so Dispose's shutdown _gate.Wait() can't deadlock against it).

All three gate consumers (ApplyAsync, RevertAsync, RecoverPendingAsync) are now consistent.

Test

RecoverPendingAsync_WaitsForGate_WhenARevertHoldsIt — reuses the file's existing deterministic seam (GatedRevertTweak, which suspends on a signal the test controls — no wall-clock): with a revert suspended holding _gate, RecoverPendingAsync()'s returned Task is asserted not completed (it's parked on _gate.WaitAsync); after Resume(), both complete and the ActiveSession marker is cleared exactly once. The pending session uses an all-false profile so recovery's own revert is an inert no-op (no power/registry/service call) — fully deterministic, touches nothing on the machine.

Red→green: pre-fix (ungated) RecoverPendingAsync completes immediately even while the revert holds the gate, so Assert.False(recover.IsCompleted) fails; post-fix it blocks on the gate → passes. (dotnet test not run locally per repo policy; verified via CI.)

Regression sweep

• dotnet build main + tests: 0 warnings / 0 errors.
• Leak-term + debug-code scan on both touched files: clean.
• Author headers intact; version bumped 1.52.98 → 1.52.99; CHANGELOG entry in this PR.