fix(workspace): a live activity line and "Steps could not be read" never share a Work card (#3357)

[dolho]

Summary

A running Workspace Work card could say the agent is working (the live activity line) and, on the line below, "Steps could not be read right now." This happened whenever the agent had a second run in flight. This PR fixes it in two places.

• The principle, at the card. stepsLine takes the card's live signal. While an activity line is on screen, an unknown read renders nothing (stages still render). A run that visibly reports progress is never called unreadable, whatever the feed sends. The chat card keeps its reserved row blank, so nothing shifts.
• At the source. client_portal/work/service.py set every card of an agent with two or more live runs to unknown without reading. The pipeline is now read once for such an agent:
  • an agent that publishes no pipeline reads none on every card, so no sentence;
  • reported stages, which an agent-written updated_at cannot attribute to one run, stay unknown.

Reproduction (local, dev b70a85a)

Two async tasks on one agent. While they overlapped, both cards read unknown. When one finished, the other went back to none.

Tests

• tests/unit/test_ent525_portal_work.py: two runs on an agent with no pipeline read none (one read, not per run); a failed read stays unknown; reported stages across two runs stay unknown. With service.py reverted to dev, 2 fail.
• src/frontend/tests/unit/workStepsActivity.spec.js: stepsLine with a live signal; a mounted card with an activity line and an unknown read never shows the sentence (both card forms, and the reserved row stays blank). With the card change reverted, 3 fail.
• Locally: backend 80 passed (ent525 + ent620); vitest 47 passed (portalWork + workStepsActivity); raw-colour and loading-gate ratchets 20 passed.

Fixes #3357

🤖 Generated with Claude Code

[dolho]

Before:

After:

[vybe]

merge-train: batch validated on train PR #3409 (all checks green, including journey-smoke, frontend-e2e and prod-image-smoke). Validation found no critical issue. Non-blocking notes for a follow-up: the 'sentence comes back' half of the new spec's last case never executes its else branch; a fresh run beside a stale row on the same agent is now read rather than both reading unknown (untested, unstated); three docs still say two runs on one agent read unknown.