docs: clarify Memcached lock limitations

Signed-off-by: memleakd <121398829+memleakd@users.noreply.github.com>

Author: memleakd

user_guide_src/source/changelogs/v4.8.0.rst

@@ -225,7 +225,7 @@ Libraries
 
 - **Context**: This new feature allows you to easily set and retrieve normal or hidden contextual data for the current request. See :ref:`Context <context>` for details.
 - **Images:**: Added support for the AVIF file format.
-- **Locks:** Added :doc:`Atomic Locks </libraries/locks>` for owner-aware, cross-process mutual exclusion backed by supported cache handlers: **File**, **Redis**, **Predis**, and **Memcached**.
+- **Locks:** Added :doc:`Atomic Locks </libraries/locks>` for owner-aware, cross-process mutual exclusion backed by supported cache handlers: **File**, **Redis**, **Predis**, and **Memcached**. Memcached support has driver-specific release limitations because Memcached has no atomic compare-and-delete command.
 - **Logging:** Log handlers now receive the full context array as a third argument to ``handle()``. When ``$logGlobalContext`` is enabled, the CI global context is available under the ``HandlerInterface::GLOBAL_CONTEXT_KEY`` key. Built-in handlers append it to the log output; custom handlers can use it for structured logging.
 - **Logging:** Added :ref:`per-call context logging <logging-per-call-context>` with three new ``Config\Logger`` options (``$logContext``, ``$logContextTrace``, ``$logContextUsedKeys``). Per PSR-3, a ``Throwable`` in the ``exception`` context key is automatically normalized to a meaningful array. All options default to ``false``.
 

user_guide_src/source/libraries/locks.rst

@@ -19,9 +19,10 @@ critical section, and release it when the work is finished.
 Configuration
 *************
 
-The Locks library uses the Cache service. The cache handler must support atomic
-lock operations. The built-in **File**, **Redis**, **Predis**, and
-**Memcached** cache handlers support locks.
+The Locks library uses the Cache service. The cache handler must support
+owner-aware lock operations. The built-in **File**, **Redis**, and **Predis**
+cache handlers support atomic lock operations. The **Memcached** cache handler
+also supports locks, with Memcached-specific limitations described below.
 
 .. note:: Locks are most useful when all competing processes share the same cache
     storage. The File handler is suitable for a single server. For multiple
@@ -34,9 +35,13 @@ lock operations. The built-in **File**, **Redis**, **Predis**, and
     store for locks when that separation is important.
 
 .. note:: Memcached lock support requires the ``memcached`` PHP extension.
-    The older ``memcache`` extension does not provide the CAS operations needed
-    for owner-aware release and refresh. Memcached locks may also be lost if the
-    Memcached server restarts, evicts keys, or flushes its cache.
+    The older ``memcache`` extension does not provide the CAS operations used
+    for owner-aware refresh and best-effort release. Memcached does not provide
+    an atomic compare-and-delete command, so releasing a Memcached lock cannot
+    provide the same owner-checked atomic release guarantee as Redis or Predis.
+    A delayed release may delete a lock that expired and was acquired by another
+    owner. Memcached locks may also be lost if the Memcached server restarts,
+    evicts keys, or flushes its cache.
 
 .. note:: File-backed locks clear released and expired lock contents, but may
     leave empty lock files in the cache directory. These files do not represent