feat: add forgetting-candidate recommendations from existing lifecycle signals

[maehwasoo]

Problem statement

We need a safe and consistent way to decide which notes should be reviewed for forgetting (archive/cleanup) without adding new frontmatter fields.

Today, this requires manual multi-step checks across status, updated, created, and graph connectivity (typed-link in/out edges), which is slow and inconsistent across operators.

As a result:

• Candidate selection quality varies by operator.
• Cleanup decisions are hard to explain/reproduce.
• Risk increases for over-aggressive cleanup when link impact is not evaluated consistently.

Proposed solution

Add a new read-only MCP tool that recommends forgetting candidates based on existing signals:

• Tool name (proposal): recommend_forgetting_candidates
• Signals (no new schema fields):
  • status
  • updated
  • created
  • typed-link connectivity (find_typed_links_incoming-equivalent backref strength, optional outgoing context)
• Candidate scoring should be deterministic and explainable (reason codes in output).

Suggested minimal contract:

• Inputs:
  • path_prefix?
  • statuses_any?
  • updated_before_days?
  • created_before_days?
  • max_incoming_links?
  • max_candidates?
• Output per candidate:
  • path
  • score
  • reasons[] (e.g. stale_updated, stale_created, low_connectivity, status_draft)
  • suggested_action (keep | review | archive_candidate)

Guardrails:

• Recommendation only (no writes/deletes).
• Use existing write workflow/tools for any follow-up action.
• Never auto-delete from this tool.

Constraints / context (optional)

• Must not require adding new note frontmatter keys.
• Prefer DB-backed analysis first to keep performance stable on large vaults.
• Keep behavior explainable (no opaque/black-box ranking).
• Should align with existing maintenance workflows and typed-link ontology docs.