Cancel API returns 404 for workers shown as running in UI

Summary

The /api/channels/cancel endpoint exists and is correctly registered, but returns 404
when attempting to cancel workers that appear as "running" in the UI.

Root Cause

There is a data source mismatch between the workers list and the cancel API:

channel_states is only populated when a new inbound message is received in the
current server session (main.rs:1618). On server restart, this map is empty.

Meanwhile, list_workers reads from the database, which still shows workers as
\"running\" because there is no cleanup of stale worker rows on startup.

As a result:

1. Server restarts (for any reason)
2. DB still shows worker as \"running\" → UI shows Cancel button
3. channel_states is empty → cancel_process returns 404 NOT_FOUND

Steps to Reproduce

1. Start a long-running worker via a Telegram message
2. Restart the server
3. Open the Workers page — worker still shows as "running"
4. Click Cancel → POST /api/channels/cancel returns 404

Suggested Fix

On server startup, mark all workers with status = "running" as interrupted/cancelled
in the DB, so the UI does not show a Cancel button for workers that can no longer be
cancelled via the in-memory API.

Alternatively, the cancel API could return a more descriptive error (e.g. 410 Gone or
a JSON error body) rather than a bare 404, to distinguish "channel not found in memory"
from "endpoint not found".

Environment

• Endpoint: POST /api/channels/cancel
• Reproducer payload: {"channel_id":"telegram:373412422","process_type":"worker","process_id":"11bb8879-fde7-4005-8d52-30c77cdd1a93"}

Start by tracing the startup path and the worker-list and cancel handlers for /api/agents/workers and /api/channels/cancel, including main.rs:1618. Confirm how persisted running rows and in-memory channel_states diverge after restart. Done means stale workers no longer appear cancellable, or the cancel response clearly distinguishes missing in-memory state from an unknown endpoint.