fix(settings): re-check lock removals at their durable commit points

A lock removal that passed the unlocked check before its write is asked
again right after the store write and, for Xtream, after the index
stamps. A relock in between writes the previous store back or rolls the
stamps back before anything is published. The stale-index bookkeeping,
index stamping and store merge move into helpers to keep the lock store
within the file size limit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture/parental-lock.md

@@ -416,7 +416,11 @@ by the index alone:
   unlocked, checked inside the write queue at commit time
   (`ParentalLockLockStore.setRemovalGate`, set by `ParentalLockService`).
   An editor opened while unlocked may still be saving, or queued behind
-  another write, when the app relocks. Adding locks is always allowed.
+  another write, when the app relocks. The answer is asked again at the
+  durable commit points: right after the store write (a refusal writes the
+  previous store back) and, for Xtream, after the index stamps (a refusal
+  rolls back like a failed stamp), before the revision is published.
+  Adding locks is always allowed.
   Playlist deletion and "Remove all playlists" are not edits and are not
   gated.
 - Every launch re-derives the index from the store for each playlist that