[LockManager] Add scenarios to Lock manager readme

packages/kbn-lock-manager/README.md

@@ -3,6 +3,14 @@
 A simple, distributed lock manager built on top of Elasticsearch.  
 Ensures that only one process at a time can hold a named lock, with automatic lease renewal and token fencing for safe release.
 
+### Typical scenarios
+
+**Re-indexing**
+Starting multiple re-index operation on the same source simultaniously can lead to data corruption. Wrapping the re-index call in `withLock("my_reindex")` guarantees that only one consumer can start the operation.
+
+**Bootstrapping tasks**
+On Kibana startup you might need to run migrations, create/update index mappings or bootstrapping other types of assets. Without a lock, every Kibana node that boots in parallel will try to run the same migrations. A lock ensures that the startup migrations only runs exactly once, even if multiple Kibana nodes spin up concurrently.
+  
 # API Documentation
 
 ## `withLock<T>(lockId, callback, options)`
@@ -51,4 +59,4 @@ Each lock has a short, fixed lifespan (default 30s) and will automatically expir
 Note: If Kibana node crashes, another process could acquire the same lock and start that task again when the lock automatically expires. To prevent your operation from running multiple times, include an application-level check (for example, querying Elasticsearch or your own status flag) to verify the operation isn’t already in progress before proceeding.
 
 **Token Fencing**
-Each lock operation carries a unique token. Only the process with the matching token can extend or release the lock, preventing stale holders from interfering.
+Each lock operation carries a unique token. Only the process with the matching token can extend or release the lock, preventing stale holders from interfering.