feat(memory): Add status metadata and session-scoped retrieval for action-oriented memories

[Fearvox]

Problem

When EverMemOS is used with long-running agents (e.g., OpenClaw 24/7 agents), completed action items from past sessions are retrieved alongside current context. The agent then re-executes already-finished tasks because it cannot distinguish resolved actions from active ones.

Root cause

1. No status metadata on memories — completed and pending action items look identical in retrieval results.
2. No session boundary awareness — retrieval treats all memories equally regardless of which session produced them.
3. No relevance decay for action-oriented memories — a "deploy X" instruction from 3 days ago has the same retrieval weight as one from 5 minutes ago.

Real-world impact

In production OpenClaw deployments, we observe:

• Agents re-running deployment scripts that already succeeded
• Duplicate messages sent because a "send update to user" memory resurfaces
• Manual workaround required: prefixing resolved items with [RESOLVED] markers in memory text

Proposed Solution

1. Status metadata on memories

Add an optional status field to memory entries:

{
  "content": "Deploy hotfix to production",
  "type": "episodic",
  "status": "resolved",
  "resolved_at": "2026-03-22T10:30:00Z"
}

Possible values: active (default) | resolved | superseded

2. Session-scoped retrieval option

Add a session_id field to memories and a retrieval filter:

GET /api/v1/memories?session_id=abc123&include_resolved=false

This allows agents to scope retrieval to the current session while optionally including cross-session context.

3. Relevance decay for action memories

For memories tagged as action-oriented (trait type or custom tag), apply a time-based decay factor to retrieval scoring. Informational memories (facts, preferences) would remain unaffected.

Alternatives Considered

• Client-side markers ([RESOLVED] prefix in text): Currently used as a workaround. Fragile — depends on LLM parsing text markers correctly.
• TTL-based expiry (related to Memory write pipeline: add deduplication for episodic/event_log and expiry cleanup for foresight #95): Too blunt — expires all memories, not just completed actions.
• Manual deletion: Loses valuable historical context that may be useful for retrospectives.

Additional Context

• We run EverMemOS with OpenClaw agents across Telegram, WeChat, and Discord channels with shared groupId.
• The agent_memory branch plugin is the integration point.
• Happy to contribute implementation if the team aligns on the approach.