Workflow runs and agent tasks are only observable on their own routes — surface them in the channel

[ttalkkaklab]

Motivation

Work is dispatched from a channel: you mention an agent, or a trigger fires a
workflow, and from that point the run lives somewhere you cannot see from the
place you started it. WorkflowRunTrace renders under the /workflows route,
and the task counters live in Projects (Work Queue → Tasks, see #6976). The
channel header itself (desktop/src/features/messages/ui/MessageHeader.tsx,
106 lines today) carries no run state at all.

The gap that costs the most is a stalled run. RunStatus is
Running | Completed | Failed (crates/buzz-workflow/src/lib.rs), but a run
that ends in Failed leaves nothing behind in the channel except the agent's
last message. Someone watching the conversation has no signal that the work
stopped, and no way to tell "still thinking" from "died four minutes ago"
without leaving for another route.

This bites hardest on a headless fleet — several agents parked on an always-on
host, driven entirely through channels, where nobody is sitting on the
/workflows page.

Proposed solution

A tab strip (or a collapsible drawer) in the channel header listing the
workflow runs and agent tasks that originated in this channel:

• current status per entry, the step it is on, and when it last moved
• a stalled or failed entry is visually distinct from a running one
• an action on a stalled entry to resume or retry it. I could not find a
  resume/retry path in the current tree — rg 'resumeRun|retryRun|rerun'
  over desktop/src and crates/buzz-workflow/src returns nothing relevant —
  so if that is genuinely absent, the engine-side half is the larger piece of
  this issue and could ship separately from the UI.
• a link from an entry to the workflow definition, for the case where the
  answer is not "run it again" but "the task was wrong".

Alternatives considered

• Keep everything on /workflows. Works when you are supervising workflows as
  workflows; it does not when the workflow is a side effect of a conversation
  you are already in.
• Fold this into Configurable orchestration workflows (user-defined; agent + human-in-the-loop; progress + artifacts) #3871. That issue proposes a configurable orchestration engine
  and lists an in-channel progress surface among its goals. This issue is
  deliberately the smaller slice: observability and resume on the engine that
  exists today, with no changes to the workflow definition format. If the
  maintainers would rather see it land as part of Configurable orchestration workflows (user-defined; agent + human-in-the-loop; progress + artifacts) #3871, closing this in favour
  of that one is fine by me.

Additional context

Related, none of them the same request:

• Configurable orchestration workflows (user-defined; agent + human-in-the-loop; progress + artifacts) #3871 — orchestration engine redesign; in-channel progress is one of its goals
• Taskboard (kanban) experiment — Nostr event kinds, relay-signed shadow updates, agent dispatch #4877 — taskboard (kanban) experiment over Nostr event kinds
• Desktop task counters are capped and can move backward after 200 issues #6976 — Work Queue → Tasks counters; shows where the task surface lives today

Read against 8d2d0ff (desktop/src/features/workflows/ui/WorkflowRunTrace.tsx,
desktop/src/features/messages/ui/MessageHeader.tsx,
crates/buzz-workflow/src/lib.rs).