Desktop: stale followup.paused marker persists after interrupting a turn with a new message

Describe the bug
On the desktop client (v1.18.11), if a running turn is interrupted because the user submits a new message (the client doesn't queue, it interrupts the old task), the old task lingers in the UI forever — it never updates to the new state. The followup.paused marker for the session is never cleared.

To reproduce

1. Start a long-running task in a session (e.g. ask the agent to do something that takes a while).
2. While it is still executing, submit a new message (which interrupts the current turn).
3. The old task remains visible/stuck in the UI ("paused" state), never replaced by the new turn's state.

Expected behavior
Submitting a new message should clear the stale paused marker, just like sending a followup draft does.

Analysis (from inspecting the v1.18.11 renderer bundle)

• Interrupting sets the marker: onAbort → setFollowup("paused", sessionID, true).
• The marker is only cleared in two paths:
  1. manually resuming a followup item (setFollowup("paused", sessionID, undefined) when manual),
  2. sending a followup draft (sendFollowupDraft clears failed and paused).
• The normal prompt submission path (api.prompt) does not clear followup.paused, so after an interrupt followed by a new message the session stays marked paused forever.

Persisted evidence: the workspace state file (opencode.workspace.*.dat) contains "workspace:followup": "{\"items\":{},\"failed\":{},\"paused\":{\"ses_...\":true},\"edit\":{}}" — the paused flag survives client restarts.

Suggested fix
In the prompt submit handler (the same place sendFollowupDraft clears the flags), also clear the paused marker:
setFollowup("paused", sessionID, undefined) before/alongside api.prompt(...).

Environment

• Desktop client v1.18.11 (Windows 11)
• Server: bundled sidecar