feat(store): cross-project memory inheritance for shared knowledge

[GravityZenAI]

Feature Description

Patterns, conventions, and learnings often apply across multiple projects. Currently, each project is a fully isolated silo. An agent working on Project B has no visibility into lessons learned in Project A, even when both projects share the same stack, team, or architectural patterns.

Real-world example: You learn "always use parameterized queries to prevent SQL injection" while working on Project A. When you start Project B (same stack), that knowledge is invisible — the agent has to re-discover it or the user has to re-state it.

Proposal

A memory inheritance system where observations can be marked as "inheritable" and automatically surface in related projects.

Scope extension:

Current scopes:  project | personal
New scopes:      project | inheritable | personal

MCP tool changes:

• mem_save(scope: "inheritable", inherit_to: ["*"]) — visible to ALL projects
• mem_save(scope: "inheritable", inherit_to: ["project-a", "project-b"]) — visible to specific projects
• mem_context(project: "project-b") — automatically includes inherited observations, clearly labeled as [inherited from: project-a]
• mem_search(project: "project-b", include_inherited: true) — search across own + inherited observations

Schema:

ALTER TABLE observations ADD COLUMN inherit_to TEXT DEFAULT NULL;
-- NULL = not inheritable (standard project scope)
-- "*" = inheritable to all projects
-- "project-a,project-b" = inheritable to specific projects

Display in results:

[inherited from: global] Always use parameterized queries for SQL
[inherited from: project-a] Supabase RLS requires service_role key for admin operations
[own] Fixed pagination bug in user list endpoint

Use cases

1. Security patterns: "Never store secrets in code" applies everywhere
2. Stack conventions: "We use Zustand for state management" — shared across all React projects
3. Team standards: "PR descriptions must include test plan" — universal
4. Learned the hard way: "SQLite BUSY errors occur with concurrent writes — use WAL mode" — save every future project from re-discovering this
5. Personal preferences: "Moisés prefers Spanish responses" — scope: personal already works for this, inheritable extends it to project-level patterns

Inheritance resolution

When mem_context or mem_search returns results:

1. Own observations (project scope) come first
2. Inherited observations follow, labeled with source
3. If an own observation contradicts an inherited one, the own observation takes precedence

Design principles

• Opt-in: no observation is inheritable by default
• Explicit: agent must intentionally mark something as inheritable
• Transparent: inherited observations are clearly labeled with their source
• Overridable: project-level observations take precedence over inherited ones
• No circular inheritance: observations inherit down, never up

Related

• Synergizes with Knowledge Graph (Proposal: Five-Layer Memory Enhancement (Semantic Search, Salience, Graph, Consolidation, Priming) #168 Layer 4) — inherited observations could be linked via the graph to show provenance
• Complements mem_merge_projects — inheritance is lighter than merging, allows knowledge sharing without consolidation
• Related to feat(store): add project aliasing system to group related projects #104 (project aliasing) — aliasing groups projects, inheritance shares knowledge between them

Affected Area

Store (schema + scope logic), MCP tools (mem_save, mem_context, mem_search), CLI, TUI