feat: add project field for cross-project memory isolation and retrieval

[RutgerBos]

Problem

All memories live in a single flat namespace. When the assistant is used across multiple projects, semantically similar memories from different projects contaminate search results. There is no way to say "search only within project X" or "search everything except project X".

The existing category field is used for topic classification (e.g. "debugging", "deployment") and should not be overloaded with project identity.

Solution

Add a first-class project field (a plain string, e.g. "A-mem", "mcp-stuff") to:

• MemoryNote dataclass
• All metadata dicts in AgenticMemorySystem (add_note, update, consolidate_memories, _load_memories_from_chromadb)
• ChromaRetriever.search() — accept an optional where filter, pass to ChromaDB's collection.query(where={"project": project}) when set
• AgenticMemorySystem.search_agentic() (and sibling search methods) — accept and pass through optional project filter
• MCP tool signatures: add_memory, search_memories, update_memory, get_memory

Behaviour

• add_memory(content, project="A-mem") — tags memory to that project
• search_memories(query, project="A-mem") — returns only A-mem memories
• search_memories(query) — no filter, returns from all projects (cross-project retrieval)
• update_memory(id, project="new-project") — allows reassigning a memory's project

Why not category?

category is already used for semantic classification of the memory's topic. project is orthogonal — a memory can be category="debugging" in project="A-mem" or category="debugging" in project="mcp-stuff". They should vary independently.

[everest-an]

Cross-project memory isolation is one of the hardest problems in agent memory design. We've been working on this at scale with Awareness (https://awareness.market — persistent memory cloud for AI agents) and found a few patterns:

1. Namespace-based isolation: Use project IDs as vector metadata filters, not just embeddings. This keeps retrieval fast even with millions of memory entries across projects.

2. Shared memory pools: Some projects benefit from shared knowledge (e.g., coding conventions, team patterns). A "global + project-specific" dual-layer works well — query global first, then filter by project.

3. Memory decay: Older memories should gradually lose weight unless actively referenced. We use a time-decay factor in the retrieval score, which prevents stale context from polluting new sessions.

Happy to share more details on our architecture if useful. The key insight is that memory isolation isn't just a data problem — it's a retrieval scoring problem.