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, 3 insertions, 1 deletions

diff --git a/scripts/chat.py b/scripts/chat.py
index e19fb6b..5b44b64 100755
--- a/scripts/chat.py
+++ b/scripts/chat.py
@@ -78,9 +78,11 @@ def reply(thread, text):
             with open(tmp, 'w') as fh:
                 json.dump(msgs, fh, ensure_ascii=False)
             os.chmod(tmp, 0o664)
+            # replace INSIDE the lock: doing it after unlock lets a second writer read
+            # the pre-replace snapshot and rename over this message (lost update).
+            os.replace(tmp, path)
         finally:
             fcntl.flock(lock, fcntl.LOCK_UN)
-    os.replace(tmp, path)          # atomic: a poll never sees a half-written file
     return msg