add-a-workflow.md step 4 doesn't reflect ui/cli/src/commands/ wrapper structure

[ooloth]

Why

A reader following step 4 verbatim will inline the workflow call in main.rs and skip creating ui/cli/src/commands/<name>.rs, breaking the convention every existing command follows.

Current state

Step 4 says to add a match arm in ui/cli/src/main.rs that calls workflows::<name>::run(...) directly. The actual pattern: main.rs declares mod commands; and delegates via Commands::Status => commands::status::run(&config).await?. The runner lives in ui/cli/src/commands/status.rs, not inline.

Ideal state

Step 4 is replaced with "Wire into hub status", which documents the unified pipeline pattern:

1. Add one or more StatusItem variants for the new item type(s) in workflows/src/status.rs
2. In workflows::status::run, push the new workflow's items into the shared Vec<StatusItem>
3. Add a render_line match arm for each variant in ui/cli/src/commands/status.rs

This is consistent with how every existing workflow (GitHub PRs, issues, CI, Linear, Sonarr) plugs in after #26 lands.

Starting points

• docs/playbooks/add-a-workflow.md step 4
• workflows/src/status.rs — StatusItem enum and run() function
• ui/cli/src/commands/status.rs — render_line match arms

QA plan

1. Read the updated step 4 — expect it to describe adding StatusItem variants and render_line arms, not inline match arms in main.rs
2. Trace a new workflow from StatusItem variant through run() to render_line — expect the playbook description to match this path exactly

Done when

A new agent following step 4 produces a structure that matches the existing workflow integrations.