fix(chat): three concurrency holes found reviewing my own patch (v4.6.77)

1. chat.py renamed the temp file AFTER releasing the flock, so two writers could each
   read the pre-replace snapshot and the later rename silently dropped the earlier
   message. os.replace now happens inside the lock.
2. The agent cursor was global. After hermes-reset it pointed past the end of the new
   empty thread, so every read returned nothing — the agent would think it had been
   ignored. Key is now per thread and reset clears every chat cursor.
3. chat-relay.sh had no overlap guard: a slow agent run (up to 5 min) could collide with
   the next tick and answer the same thread twice. flock -n on /tmp/chat-relay.lock.

Verified: stale cursor 'webx11_chat_agent_cursor_oldthread00000' set to 9999999999999,
hermes-reset -> zero cursor keys remain, read returns {messages:[], note:'no new messages...'}.

1 files changed, 4 insertions, 0 deletions

diff --git a/modules/core/module-debug-supervisor.js b/modules/core/module-debug-supervisor.js
index 6768df1..79c9acc 100644
--- a/modules/core/module-debug-supervisor.js
+++ b/modules/core/module-debug-supervisor.js
@@ -173,6 +173,10 @@ class DebugSupervisorModule {
         try {
             localStorage.removeItem('webx11_chat_token');
             localStorage.removeItem('webx11_chat_state');
+            // a stale agent cursor would point past the end of the new, empty thread
+            Object.keys(localStorage)
+                .filter(k => k.indexOf('webx11_chat_agent_cursor') === 0)
+                .forEach(k => localStorage.removeItem(k));
             this.terminal.print('🔄 Chat token rotated — a new thread starts with your next message', 'success');
         } catch (e) {
             this.terminal.print('❌ ' + e.message, 'error');