fix: prevent session_start() lock errors with Memcached handler

Fixes #7604

When using Memcached as session handler with concurrent AJAX requests,
session_start() could throw 'Unable to clear session lock record' warning.
Two issues contributed:

1. MemcachedHandler::close() did not reset $this->lockKey and $this->lock
   after deleting the lock, unlike releaseLock(). This could leave PHP's
   session handler in an inconsistent lock state between requests.

2. PHP has a known limitation with custom session handlers where lock
   cleanup warnings can occur during concurrent access. Using error
   suppression on session_start() prevents these from becoming fatal
   errors in production.

Changes:
- MemcachedHandler::close(): reset lockKey and lock after delete
- Session::startSession(): add @ to session_start() with explanatory
  comment about PHP's custom session handler limitation

Note: RedisHandler and DatabaseHandler already properly managed lock
state in their close() methods.

Ref: #7604

Author: jalexiscv

system/Session/Handlers/MemcachedHandler.php

@@ -225,6 +225,8 @@ public function close(): bool
         if (isset($this->memcached)) {
             if (isset($this->lockKey)) {
                 $this->memcached->delete($this->lockKey);
+                $this->lockKey = null;
+                $this->lock    = false;
             }
 
             return true;

system/Session/Session.php

@@ -622,7 +622,10 @@ protected function startSession()
             return;
         }
 
-        session_start(); // @codeCoverageIgnore
+        // Error suppression is used to prevent warnings when
+        // concurrent requests cause session lock conflicts.
+        // This is a known PHP limitation with custom session handlers.
+        @session_start(); // @codeCoverageIgnore
     }
 
     /**