Completed dream state blocks chat until explicit wake

[NealZhouPanda]

Bug Description

When a dream cycle reaches finished_idle, the server keeps the persistent state as is_dreaming = 1. Subsequent user messages are rejected with a dreaming error instead of receiving a reply.

This makes the desktop companion appear unresponsive: the user sends a chat message, but Luna does not answer.

Steps to Reproduce

1. Start or wait for a dream cycle to complete.
2. Let the cycle reach finished_idle.
3. Send a normal chat.send message from the desktop client.

Actual Behavior

The WebSocket server rejects the message with:

{
  "type": "error",
  "code": "dreaming",
  "message": "Luna is dreaming — send dream.wake to wake her"
}

The failed turn does not produce a turn.result or a persisted assistant reply, so the user only sees no response in the chat UI.

Expected Behavior

A completed dream should not silently block normal chat. One of these behaviors would be safer:

• automatically return to the awake/chat state when the cycle reaches finished_idle; or
• clearly expose the dream state in the desktop UI and reliably send dream.wake; or
• queue the user's message and process it after waking.

At minimum, a user message should result in a visible, actionable state rather than appearing to be ignored.

Evidence

On the affected instance:

• dream_state.is_dreaming = 1
• dream_state.current_step = "finished_idle"
• the LLM API itself responded successfully to a minimal request
• after restarting Luna, boot reconciliation changed the stale dream state to awake and the same WebSocket chat path returned a normal turn.result

Environment

• OS: macOS 26.6.1
• Luna.app: 0.1.0
• Client: desktop app