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.