bug(conflicts): legacy pending relations with absent endpoints remain unreviewable and undiagnosed

[JuanjoPas]

📝 Bug Description

engram conflicts stats --all counts pending relations whose both observation endpoints are absent from the active observation set. These cannot be reviewed with mem_get_observation/project-scoped conflict listings, yet remain pending indefinitely. engram doctor --json does not flag them, and the documented conflict/doctor maintenance commands provide no safe way to classify or reconcile them. This is a local relation-lifecycle/diagnostics gap, distinct from the export/import failure fixed in #1291.

🔄 Steps to Reproduce

1. Use a store containing historical memory_relations rows in judgment_status=pending whose source and target observations have since been hard-deleted or otherwise are not present in the active export. (This report is based on an existing store; I did not mutate it to manufacture the condition.)
2. Run engram conflicts stats --all, then engram conflicts list --all --status pending --limit 1 and engram conflicts show <relation_id>.
3. In a private directory, run engram export <private-export.json> --all. Compare relations[] with judgment_status == "pending" against the set of observations[].sync_id, checking both source_id and target_id. Do not publish the export: it contains private memories.
4. Run engram doctor --json and compare engram conflicts stats --project <active-project> for active projects.

✅ Expected Behavior

Pending relations with unavailable endpoints should not be presented as actionable semantic judgments. Doctor should report a distinct, bounded finding with counts and an evidence-preserving next step. Provide a supported, backup-first plan/dry-run/apply route that safely reconciles legacy pending rows with genuinely absent endpoints (for example, a clearly audited orphaned disposition consistent with #1291), without recreating observations, fabricating a semantic verdict, silently deleting relation audit records, or changing relations whose endpoints remain available.

❌ Actual Behavior

On Engram 2.2.1, conflicts stats --all reports 696 pending relations. In a private export --all, all 696 pending relations have neither endpoint among exported observations (0 with both active, 0 with one active). conflicts show renders blank source/target titles for sampled rows. Project-scoped pending counts are zero across the projects returned by engram projects list; the global pending count remains 696. Doctor returns 9 checks: 7 OK, 2 unrelated warnings, 0 blocked, 0 errors. The documented engram conflicts subcommands and engram doctor repair checks offer no relation-lifecycle repair route.

Operating System

Linux (Ubuntu/Debian)

Engram Version

2.2.1

Agent / Client

Other

📋 Relevant Logs

$ engram conflicts stats --all
By judgment_status:
  pending: 696

$ engram conflicts list --all --status pending --limit 1
  relation: pending
  judgment_status: pending
  source: <redacted-id> —
  target: <redacted-id> —

$ engram doctor --json | <summary-only extraction>
  total: 9, ok: 7, warnings: 2, blocked: 0, errors: 0

$ <private export audit: compare pending relation endpoints to exported observation sync_ids>
  pending: 696, both endpoints present: 0, neither present: 696, one present: 0

💡 Additional Context

Related but not duplicate: #1291 concerns lossless export/import of already-orphaned audit relations. This store still has pending relations with unavailable endpoints: the existing export includes the relations but not their observations. I did not judge them blindly or run direct database repair. A consistent SQLite backup and post-audit integrity/foreign-key checks succeeded. Please clarify whether orphaned is the intended disposition for these legacy rows, and expose a safe supported maintenance path with tests for both-endpoint-missing, one-endpoint-missing, and live-endpoint controls.

[danielgap]

Taking this one, with full credit to @JuanjoPas: the export audit breaking pending relations down by endpoint availability is exactly the evidence needed, and the acceptance criteria are already crisp.

Plan, following the issue's Expected Behavior:

1. A bounded engram doctor finding that reports legacy pending relations with absent endpoints as a distinct condition, with counts and an evidence-preserving next step.
2. A backup-first reconcile route (plan / dry-run / apply) that reclassifies only pending rows whose endpoints are genuinely absent into the audited orphaned disposition consistent with bug(store): engram export --all emits relations with absent endpoints, and import rolls back the entire restore #1291, without recreating observations, fabricating verdicts, silently deleting audit records, or touching one-endpoint-missing or live-endpoint relations.
3. Tests covering both-endpoints-missing, one-endpoint-missing, and live-endpoint control rows.

If you are already working on a fix, or maintainers prefer a different disposition for these legacy rows, I will stand down and coordinate here.

[danielgap]

Opened #1472 with the doctor finding (orphaned_pending_relations) and the backup-first reconcile route (engram doctor repair --check orphaned_pending_relations --plan|--dry-run|--apply), with the three-scenario test matrix from the issue. The orphaned disposition is reused exactly as #1291 established it, and one-endpoint-missing or live-endpoint relations are never touched.