fix(server): treat all-silent comply tracks as passing, not degraded

[bokelley]

Closes #4065

Summary

When comply() returns silent for every track (all scenarios passed, zero failures — the best possible outcome), the SDK reports overall_status: 'partial'. The server mapped 'partial' → ComplianceStatus: 'degraded', so the dashboard showed "Compliance: Degraded" for fully-clean agents.

Added effectiveRunStatus() in compliance-testing.ts to intercept at the DB-adapter boundary: when all active (non-skip) tracks are 'pass' or 'silent', override to 'passing' and recompute tracks_passed, tracks_failed, and tracks_partial so stored run records stay consistent. The SDK result itself is untouched. Frontend: five locations in agents.html and dashboard-agents.html (card, detail modal, history panel, track-detail drawer) now map 'silent' track pills to the pass CSS class.

Non-breaking justification: Server-internal status computation correction. No schema, API, or protocol changes. ComplianceStatus values are unchanged; only their mapping from SDK output is corrected. Existing DB records stay as-is until the next heartbeat cycle.

Downstream effects (all correct behavior):

• Streak accumulation now works for all-silent agents (streak_days advances correctly)
• last_passed_at is now set on all-silent heartbeats (was NULL, blocking badge eligibility)
• Compliance notifications no longer false-fire for agents with clean-but-silent runs

Known secondary gap (not fixed here): member-tools.ts:3533 records overall_passed: result.overall_status === 'passing' using the raw SDK string, which stays 'partial' for all-silent runs. The quality_evaluation tool's recordTest call will incorrectly store overall_passed: false until a follow-up PR.

Deploy consideration: Agents currently stored as status='degraded' due to this bug will trigger a one-time "recovery" status notification on their next heartbeat post-deploy (transition degraded → passing). This is a one-off spurious recovery DM, not a regression notification. Operators receiving it may be briefly confused; the message will show correct data about the agent's healthy state.

Pre-PR review

First review pass (before addressing blockers):

• code-reviewer: Found 5 locations needing silent mapping (not 4), flagged missing unit tests for effectiveRunStatus, and flagged tracks_failed inconsistency. All addressed.
• internal-tools-strategist: Flagged recovery notification risk on first post-deploy heartbeat (documented above as deploy consideration). Confirmed silent = passing display is semantically correct; streak/last_passed_at fix is correct and load-bearing.

Fixes applied after first pass:

• Added 5th silent → 'Passing' mapping in dashboard-agents.html track-detail drawer (line 2602)
• Added tracks_failed: 0 to the override branch of effectiveRunStatus
• Added unit tests (server/tests/unit/compliance-testing-effective-run-status.test.ts) covering: all-silent, mixed pass+silent, at-least-one-fail, skip-track exclusion, all-skip no-promotion

Triage-managed PR. This bot does not currently iterate on
review comments or PR conversation threads (only on the source
issue). To unblock:

• Push fixup commits directly: gh pr checkout <num> →
  fix → push.
• Or re-trigger: comment /triage execute on the source
  issue.

See #3121
for context.

Session: https://claude.ai/code/session_014sRTVL1uWrZJUj6TiJWcBS

---

Generated by Claude Code