feat(web): enlarge busy dock rings with elapsed-time and mail pills

[chriscoveries]

Summary

Makes the runtime dock read at a glance: a working actor's ring is now clearly dominant (50px frame / 7px animated stroke vs 41px / 4px idle), and each icon carries status pills so you can see how long and how much mail without opening a terminal.

• Elapsed-time pill under every icon: white-on-black while busy, grey-on-white when idle; minutes+hours only (0m, 42m, 3h12m — hours spiral, no days/seconds). Backed by effective_working_updated_at for managed actors and client-side state-change tracking for PTY actors (which have no backend timestamp).
• Down-since pill on stopped actors (Xm/XhYm since the actor.stop ledger event; falls back to observed stop time within the session).
• Mail pill (2✉6m): outstanding mail count + oldest-mail age, computed from _read_status — the same truth the Inbox badge uses.
• Icons moved closer together (tighter gap) so more actors fit the dock.

Pure frontend — no daemon, protocol, or data changes.

Testing

• npm run check (lint + tsc) clean, npm test green.
• Verified live against a running daemon: working vs stopped vs mail-pending states render as described.

Written by Devin

[ChesterRa]

Thanks for investigating these issues and putting together the PRs. The concrete failure cases are useful, and splitting the original batch into smaller changes has made the review much easier.

For CCCC’s current stage, I’d like to prioritize reliability fixes and keep the existing workflows simple. There are several changes here I’d like to bring in, with a few corrections and scope adjustments:

#116: The activity and unread indicators are useful. I’d support a focused version that uses the daemon’s authoritative unread counts, rather than calculating them from the currently loaded chat history, and keeps the activity display straightforward.

#117: I’d prefer to defer the overview redesign. The additional layout, polling, and connection visualization introduce more complexity than we need right now.

#119: This is a high-priority fix. Separating the viewer’s lifecycle from the provider job makes sense. Before merging, we need to preserve retryable ownership when an explicit stop fails; the current implementation can lose that state before confirming the provider has stopped.

#120: The cron weekday correction addresses a real frontend/backend mismatch and is worth prioritizing. The new conversion still needs a fix for ranges such as 0-7, which currently becomes Sunday only. For the configuration changes, I’d prefer to build on the existing incremental update operations and avoid adding a separate reload command unless it serves a distinct purpose.

#121: This combines several independent fixes with new behavioral policies. I’d like to review the delivery and cross-group routing fixes separately. The permission flags, task-stall detection, dialog detection, and API-prefix support need further integration work—for example, the new stall trigger is rejected by the configuration API, and the alternate API prefix breaks realtime subscriptions.

#122: The Telegram timeout handling, reply threading, and preservation of constraint text are useful improvements. The new relay mode needs to agree with the existing verbose controls: after /relay all, /verbose off currently leaves all-message forwarding enabled. I’d prefer one consistent set of controls.

#123: Clearer reconnect feedback is welcome. The countdown initialization needs a small correction, and the diagnostics should reflect the actual realtime transport. I’d keep the existing message timestamps for now; changing them to relative ages isn’t necessary for the reconnect improvement.

If you’d like to prioritize, #119 and the cron correction in #120 are the best starting points, followed by the focused fixes from #122. There’s no need to expand the larger feature proposals for this round.

I appreciate the work behind these contributions. The goal is to get the useful fixes landed with clear behavior and focused regression coverage, while keeping the ongoing maintenance burden manageable.

[ChesterRa]

Thanks again for the contributions and for splitting up the larger changes. There are useful improvements here, and I’d like to start with a focused version of #116.

Before merging it, we need to use the daemon’s authoritative unread counts rather than counting only the messages currently loaded in the UI. I’d also prefer to omit the one-hour progress arc and keep elapsed-time labels limited to what we can reliably determine. Once those changes and focused regression checks are in place, #116 would be a good first PR to land. I’m happy to handle small integration fixes while preserving your contribution credit.

For future contributions, could we follow a few simple conventions?

-Start new branches from the latest upstream main. Existing PRs can usually be updated in place; there’s no need to close and recreate them unless we’re splitting their scope.
-Keep each PR focused on one independently reviewable problem. Include the related tests and documentation, but leave unrelated fixes, refactors, and features for separate PRs.
-Keep independent PRs independent. If a PR depends on another, please state that explicitly and update it after its dependency lands.
-For new feature requests, please open an issue first so we can discuss the use case, scope, and fit with CCCC’s direction before substantial implementation work begins. We prefer agreeing on the problem and approach together before reviewing a large feature PR. This helps avoid spending significant effort on something we may not be ready to adopt. Small bug fixes and straightforward improvements can still go directly through a PR.

For the remaining work, I’d prioritize #119 and the cron correction from #120. I’d like to defer #117 for now.

The aim is to make useful changes easier to review and merge, and to avoid you spending time on work that needs substantial reshaping afterward. Thanks for working through this with us.