Detect stale pending notification backlogs for heartbeat processing

[al-munazzim]

Problem

Heartbeat policy says GitHub notifications must be processed via Argus on every heartbeat, but pending notifications can still accumulate without visible failure.

Observed on 2026-06-02:

• argus notif pull succeeded
• argus status reported Pending notifications: 17
• Activity (24h): 0
• A specific kept notification for cryptoadvance/specter-desktop#2624 remained pending:
  • notification id: 23861552859
  • reason: subscribed
  • filter: KEEP (rule): Keep all specter-desktop notifications

The workspace HEARTBEAT.md requires:

• argus notif pull
• argus status
• argus notif list --pending
• every pending notification to get either argus notif act or argus notif dismiss with a reason

So if heartbeat is the intended scheduler, Argus should make this failure mode more visible / auditable.

Expected behavior

Argus should help prevent or surface stale pending notification backlogs when heartbeat processing is missed or incomplete.

Possible approaches:

• add an argus notif audit command that exits non-zero when pending notifications exceed a threshold or oldest pending is too old
• make argus status highlight stale pending items more prominently
• add a machine-readable status output suitable for heartbeat/cron checks
• optionally create/raise an escalation when pending notifications remain unprocessed after a configured age

Actual behavior

Argus can successfully pull notifications and show pending count, but the heartbeat runner/agent can still leave pending notifications unprocessed without an explicit Argus-level failure signal.

Acceptance criteria

• There is a documented/checkable way to detect stale pending notifications.
• The command is easy to use from heartbeat automation.
• The command returns a non-zero exit code, or otherwise clearly signals failure, when pending notification processing is overdue.