Cancelled prompt leaves dangling tool chain that hijacks all subsequent messages

**Describe the bug**

When a user cancels a prompt (via stop button or closing the app) while the model is mid-tool-chain, the daemon persists the `toolRequest` and `toolResponse` rows but never writes the assistant's follow-up text response. The session's message history now ends with an unanswered tool result.

On every subsequent request, the model sees this as an unfinished turn and resumes the old task instead of responding to the user's new message.

---

**To Reproduce**

1. Start a session and ask a question that triggers a tool call
2. Cancel the prompt while the tool is executing, or immediately after the tool result returns
3. Send a new message
4. The model ignores the new message and resumes the cancelled task

---

**Expected behavior**

After a cancelled prompt, the next user message should be answered normally. The persisted history should never end on an unresolved tool result; either the interrupted pair should not be persisted, or a synthetic assistant message should close the turn.

---

**Please provide the following information**

- **OS & Arch:** macOS
- **Interface:** Goose Desktop (UI)
- **Version:** 1.50.0
- **Extensions enabled:** Analyze, Apps, Chatrecall, Code Execution, Computercontroller, Developer, Memory, Skills, Summon
- **Provider & Model:**

---

**Additional context**

**User impact:** the session becomes unusable. Every new message is hijacked by the interrupted task. Quitting and reopening Goose does not fix it. Copying the session carries the poison. The only recovery is manually deleting the dangling rows from the database.

**Evidence:** 4 sessions on this machine end with unresolved `toolResponse` rows. In the primary affected session, every new message (including trivial tests like "respond with Hello") triggered the model to resume a cancelled web-scrape task. The behavior persisted across daemon restarts and session copies because the dangling pair is persisted in the database.

**Fix suggestion:** on prompt cancellation, either (a) do not persist the `toolRequest`/`toolResponse` pair if no assistant follow-up was generated, or (b) insert a synthetic assistant message marking the turn as cancelled, so the history never ends on an unresolved tool result.

A PR is being prepared that takes approach (b): set a `was_cancelled` flag when `emit.cancelled()` fires, and after filling in interrupted tool responses, append a visible text marker `[Turn cancelled by user. awaiting the next message.]` so the conversation history never ends on a bare tool chain. Normal (non-cancelled) turns are unchanged.

daemon の prompt 処理とキャンセルロジックを見てください。おそらく `crates/daemon/src/` のようなモジュール内です。`toolRequest` と `toolResponse` の行がデータベースに永続化されている箇所を見つけてください。修正は、キャンセルをチェックし、そのペアを永続化しないか、合成の assistant message を挿入することを含みます。バグを再現してテストしてください: session を開始し、tool call をトリガーし、キャンセルして、新しい message を送信します。

索引モデルが issue の本文から書いたものです。