fix(memory): preserve encrypted SQLite history on wrong-key pops - #5083

One concurrency edge still leaves the destructive-loss bug reachable.

The original peek→pop TOCTOU is fixed, but the compensating restore still has a narrower ordering race.

Thanks for separating authentication failure from expiry. Before merging, please replace the separate destructive pop and compensating append with an operation that authenticates and conditionally removes the same record atomically at the backend boundary.

Please also replace the sequential append test with controlled interleavings covering an append and a clear during the operation, asserting final history order and that cleared records cannot reappear. The current test appends only after restoration has completed, so it does not exercise the race.

Reviewed native encrypted SQLite pop against both prior feedback threads. The same transaction now claims and authenticates the exact tail row before committing. InvalidToken rolls back rather than peeking or appending a replacement row, so identity and order survive a wrong key even during concurrent append/clear. Repeated cancellation waits for the worker to finish rollback. Authenticated expired tails still drain; overridden, wrapped and non-SQLite pops keep their original delegation behavior. The narrower atomic guarantee is accurately stated on pop_item.

The broad GitHub comparison includes 19 upstream main commits. I compared those files against pinned main: only encrypt_session.py, sqlite_session.py and test_encrypt_session.py differ, and reviewed that entire owned change with surrounding code.

All 21 exact-head hosted checks succeeded, including Python/Windows tests, native macOS, packaged contracts, lint and typecheck. The new tests pause at actual SQLite authentication and check write locking, row/order preservation, expiry, cancellation and custom-session delegation. I did not run local tests. No blocking findings.