bug(doctor): doctor reports status ok while 171 pending cloud mutations are blocked and undeliverable

[thomaspufahl]

📋 Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

📝 Bug Description

engram doctor --json returns status: ok with zero warnings on a device that has 171 pending cloud sync mutations that cannot leave the queue. The sync_mutation_required_fields check counts them (pending_mutations_evaluated: 171) and passes them, because it only validates that required fields are present and never asks whether the queue is actually draining.

The result is that doctor gives a clean bill of health to a device with an undeliverable backlog, and gives the operator no hint that anything needs attention.

🔄 Steps to Reproduce

1. Device with cloud sync configured and working.
2. Have at least one project with local observations that is not enrolled for cloud sync.
3. Generate observations in that project so mutations accumulate in the queue.
4. engram cloud status → reports the block and names the projects.
5. engram doctor --json → status: ok.

✅ Expected Behavior

doctor should surface pending mutations that are blocked or undeliverable as at least a warning, naming the affected projects, so the operator can decide whether the block is intentional or a real fault.

❌ Actual Behavior

{
  "status": "ok",
  "summary": { "total": 4, "ok": 4, "warnings": 0, "blocked": 0, "errors": 0 },
  "checks": [
    {
      "check_id": "sync_mutation_required_fields",
      "result": "ok",
      "message": "No issues detected.",
      "evidence": { "pending_mutations_evaluated": 171 },
      "safe_next_step": "No action required."
    }
  ]
}

While engram cloud status on the very same device, at the same moment, says:

Sync diagnostic: degraded
reason_code: non_enrolled_pending_mutations
reason_message: pending cloud sync mutations are blocked because project(s) are not
  enrolled: coli=11, omarchy-on-cachyos=27, pufi=66, social=49, wallpapers=18.
  Run `engram cloud enroll <project>` for each intended project or review enrollment.

11 + 27 + 66 + 49 + 18 = 171 — exactly the mutations doctor evaluated and approved.

Operating System

Linux (Arch / CachyOS), kernel 7.0.8-1-cachyos. Same behaviour on Windows 11 with a different project.

Engram Version

1.20.0 (client and self-hosted cloud server both on v1.20.0)

Agent / Client

Claude Code

📋 Relevant Logs

$ engram doctor
Checks: 4 ok=4 warnings=0 blocked=0 errors=0

💡 Additional Context

To be explicit about scope: in our case those five projects are intentionally local-only, so the block itself is correct behaviour and we do not want them enrolled. The bug is that doctor emits no signal whatsoever — it cannot distinguish "intentionally local" from "queue jammed" and reports a clean result for both. A warning naming the projects would let the operator make that call, which is information engram cloud status already has and doctor discards.

This matters because doctor is the natural thing to script for per-device sync monitoring. Paired with the companion issue where /sync/status reports degraded on a device that is syncing fine, both available signals are unreliable — one optimistic, one pessimistic. Diagnosing a real incident with them produced three consecutive wrong conclusions.

[thomaspufahl]

Companion issue: #687 — /sync/status reports degraded with last_sync_at: null on a device that is syncing correctly. Together they mean both available sync signals are unreliable, in opposite directions: this one is optimistic, #687 is pessimistic.