Urgency-ranked unified output

[ooloth]

Why

hub status renders flat sections in a fixed order, so a new CI failure and a months-old issue look equally important — defeating the "ranked by what needs attention" goal that is the core of hub's value proposition.

Current state

hub status renders four fixed sections (github prs, github issues, github ci, linear issues) with no concept of urgency. Domain types (PullRequest, Issue, CiFailure, LinearIssue) have no urgency field. Items within each section are in arrival order.

Ideal state

• Each domain type carries an urgency tier: Critical, High, Medium, or Low
• Each workflow assigns urgency based on rules it owns (e.g. CI failure = High, PR open >3 days = Medium, unassigned issue = Low)
• hub status renders a single unified list sorted by (urgency, age) — not separate sections
• The rendered line for each item includes its urgency tier so context is visible at a glance

Out of scope

• AI-assisted urgency scoring — rules first; AI is a natural later layer
• Configurable urgency thresholds in hub.toml — hardcode sensible defaults first

Starting points

• domain/src/lib.rs — domain types that need an urgency field added
• workflows/src/status.rs — where items are produced; urgency assignment lives here
• ui/cli/src/commands/status.rs — rendering logic that needs to merge and sort across types

QA plan

1. Configure hub.toml with at least one PR repo and one CI repo; ensure a known CI failure exists
2. Run hub status — expect items from all sources in a single list, with the CI failure appearing before lower-urgency items regardless of arrival order
3. With no CI failures, run hub status — expect PRs and issues sorted by age within their urgency tier
4. Add a 0-day-old issue and a 5-day-old PR at the same urgency tier — expect the PR (older) to appear above the issue

Done when

hub status renders items from all sources in a single list ordered by (urgency, age), with no fixed section order.