Add force follow-up mode to interrupt a running task

[afurm]

Problem

When a task execution is already queued or running, the task detail follow-up composer currently sends the new prompt as a normal follow-up and tells the user: "Follow-up queued. It will start after the current work finishes."

That behavior is useful for ordinary follow-ups, but it is not enough when the user realizes the active agent run is going in the wrong direction and needs to correct course immediately. In that case the new prompt should be able to interrupt the active work instead of waiting behind it.

Proposal

Introduce an explicit force follow-up mode, for example an Interrupt and run / Force request control in the task detail follow-up composer when the latest execution is active.

Expected behavior:

• Keep the existing normal follow-up behavior unchanged: follow-ups submitted during an active run are queued behind the current work.
• Add a separate force action that cancels or interrupts the current active execution for the task and starts the user's new follow-up as the next execution without waiting for the active run to finish naturally.
• Preserve execution history so the interrupted run remains visible as cancelled/interrupted, and the force follow-up is recorded as its own follow-up execution.
• Make the action visually distinct from normal follow-up submission because it intentionally stops active work.
• Avoid losing the user's prompt if cancellation or the forced start fails; keep it retryable in the UI.

Implementation notes

Current relevant seams:

• src/client/components/TaskModal.tsx already knows when an execution is active and currently reports queued follow-ups during a run.
• src/server/task-executor.ts already has per-task execution queues plus abort/cancel handling through abortTaskExecutionForTask and active AbortControllers.
• The likely API shape could be an option on the follow-up request such as interruptExisting: true, or a separate endpoint if that keeps the semantics clearer.

The queue behavior needs special care: a forced follow-up should not sit behind the same per-task queue entry it just interrupted. Any already queued follow-ups for the same task should either stay queued behind the forced request or be explicitly cancelled/superseded, but the product should define that rule clearly.

Acceptance criteria

• While a task is running, the user can choose between normal queued follow-up and forced follow-up.
• Normal follow-up during an active run still queues and shows the existing queued notice.
• Forced follow-up interrupts the active run and starts the new prompt without waiting for natural completion.
• The interrupted execution is retained in task history with a clear cancelled/interrupted event.
• The forced execution records the user's prompt and result like other follow-ups.
• Server tests cover queue replacement/interruption behavior.
• UI tests cover the new force action, active-run-only availability, and failure/retry behavior.

[afurm]

Completed by #22.