Bug Description

When lossless-claw deferred turn maintenance is running, new inbound messages fail with:

\
Error: reply session initialization conflicted for agent:main:main
\\

Reproduction

1. Have lossless-claw enabled as context engine with \proactiveThresholdCompactionMode: "deferred"\
2. Send messages to the agent (especially in rapid succession or during active trading/chat sessions)
3. When the agent finishes a turn, lossless-claw queues deferred turn maintenance
4. If a new message arrives while maintenance is still running, the message fails with the conflict error

Observed Log Pattern

Every occurrence follows this exact sequence:

\
[lcm] auto-rotate: phase=runtime action=skip sessionId=... sessionKey=agent:main:main
[context-engine] deferred turn maintenance queued taskId=... sessionKey=agent:main:main lane=context-engine-turn-maintenance:agent:main:main
[lcm] auto-rotate: phase=runtime action=skip sessionId=... sessionKey=agent:main:main
message dispatch completed: channel=webchat sessionKey=agent:main:main source=replyResolver outcome=error error="Error: reply session initialization conflicted for agent:main:main"
\\

The error always appears in pairs (dispatch error + processed error) within ~5ms.

Frequency

• Observed 12 occurrences in a 2-minute window during an active chat session
• Observed 4 occurrences during another active session
• Correlates with rapid message sending (user sending multiple messages before agent finishes processing)

Impact

• The conflicted message is dropped - the agent never processes it
• Does not crash the gateway or affect other sessions
• Does not corrupt existing session data

Expected Behavior

New messages arriving during turn maintenance should be queued and processed after maintenance completes, rather than being rejected with a conflict error.

Environment

• OpenClaw: 2026.6.11
• lossless-claw: enabled, \proactiveThresholdCompactionMode: "deferred"\
• Node.js: v24.14.1
• OS: Windows 10 (x64)
• Channel: webchat

Workaround

Avoid sending messages in rapid succession - wait for the agent to fully respond before sending the next message.