WPB-22959 Generalize migration lock

[battermann]

Checklist

• Add a new entry in an appropriate subdirectory of changelog.d
• Read and follow the PR guidelines

[Copilot]

Pull request overview

This PR generalizes the migration lock mechanism to make it reusable beyond conversation-specific operations. The refactoring introduces a MigrationLockable typeclass that allows different types (ConvId, UserId) to use the same locking infrastructure.

Changes:

• Moved Wire.ConversationStore.MigrationLock to Wire.MigrationLock for broader reusability
• Introduced MigrationLockable typeclass with lockKey and lockScope methods
• Updated all call sites to use the new type-safe API instead of Either ConvId UserId

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
libs/wire-subsystems/wire-subsystems.cabal	Updated module exports to reflect the move from Wire.ConversationStore.MigrationLock to Wire.MigrationLock
libs/wire-subsystems/src/Wire/MigrationLock.hs	Generalized the module by introducing MigrationLockable typeclass and updating function signatures to be generic over lockable types
libs/wire-subsystems/src/Wire/ConversationStore/Migration/Types.hs	Added MigrationLockable instances for ConvId and UserId, and moved hashUUID helper function here
libs/wire-subsystems/src/Wire/ConversationStore/Migration.hs	Updated import and simplified call sites to use homogeneous lists instead of Either
libs/wire-subsystems/src/Wire/ConversationStore/Cassandra.hs	Updated import and refactored helper functions to be type-specific (withMigrationLocksAndConvCleanup, withMigrationLocksAndUserCleanup)
changelog.d/5-internal/WPB-22959	Added changelog entry documenting the generalization

Comments suppressed due to low confidence (1)

libs/wire-subsystems/src/Wire/MigrationLock.hs:93

• The logging behavior has changed from displaying the original UUID (e.g., "a1b2c3d4-e5f6-7890-abcd-ef1234567890") to displaying the hashed Int64 value (e.g., 123456789). While this is likely acceptable for migration locks since the hash is deterministic and unique, it may make debugging more difficult when comparing logs with other parts of the system that log the actual UUID values. Consider whether this trade-off is acceptable for your use case, or if you should add a method to the MigrationLockable typeclass to provide a human-readable identifier for logging purposes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[akshaymankar]

Not sure why we need -fno-warn-orphans, but looks good.