fix: keep graph_add_memory entries past the 200-entry pruning cap

[Hardik-369]

Fixes #37

What changed

graph_add_memory built its entry with a "type" key and no
created_epoch, but _prune_context_entries — which runs on every
save — reads "kind" and sorts by created_epoch. The type →
kind normalization only ran on load, never before save, so the entry
was judged in its raw form.

Missing created_epoch reads as 0, which sorts a brand-new entry
dead last in the newest-first ranking. Once the store holds 200
entries the prune loop hits its cap before reaching it, so the entry is
silently dropped while the tool still returns {"ok": true, ...}.

The entry is now written in the same normalized shape as
graph_register_edit (which ships kind, created_at and
created_epoch on every write):

now = datetime.now(timezone.utc)
entry: dict[str, Any] = {
    "kind": type,
    "content": content,
    "tags": tags or [],
    "files": files or [],
    "created_at": now.isoformat(),
    "created_epoch": int(now.timestamp()),
}

No other write path is affected — _upsert_context_memory and
graph_register_edit already write these keys, so this aligns
graph_add_memory with the rest of the codebase.

Why this PR adds the file

The core lives in the private Claude-CLI-Compact-core repo and ships
via the graperoot PyPI wheel, so this PR carries the current shipped
source (graperoot 3.10.8 wheel, mcp_graph_server.py) with the fix
applied for porting into the private repo. The diff against the
shipped file is the graph_add_memory change above only.

Testing performed

• Reproduced the bug: with a store at the 200-entry cap, the old
  entry shape (type/date, no created_epoch) is evicted by
  _prune_context_entries on save.
• Verified the fix: with the new entry shape, the entry survives
  pruning (oldest entry evicted instead) and loads back normalized
  with kind, created_epoch and a generated id.
• End-to-end: called the actual graph_add_memory tool via
  build_server() against a store pre-filled to 200 entries — returns
  {"ok": true, "total": 200} and the entry is persisted.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[kunal12203]

Thanks for the detailed analysis and fix — the bug report in #37 is excellent and your fix is correct.

However, I can't merge this PR as-is because it adds the full mcp_graph_server.py source into this (open-source) repo. The graph engine ships as compiled .so/.pyd via the graperoot PyPI package, and this repo only contains the launchers/tooling.

I'll port your fix into the next release (the 4-line change to normalize kind + created_epoch before save). Will credit you in the changelog.

Closing this, but the fix ships in the next version. Thanks!