feat(store): add project aliasing system to group related projects

[Andressc19]

📋 Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

🔍 Problem Description

Engram currently determines project identity using only the git remote URL (or basename as fallback). This creates a fundamental limitation: two repositories that logically belong to the same project are treated as completely separate projects.

Example scenarios:

• "myapp" (main repo) + "myapp-installer" (installer tools repo) → treated as different projects
• Worktrees of the same repo accessed via different paths → different project names

This leads to:

1. Memory fragmentation across "duplicate" projects
2. Inconsistent context when working on related repositories
3. No way to query or group memories across a project family

Related issue: #55 (Worktree support) - this would help with that use case.

💡 Proposed Solution

Introduce a project aliasing system that allows multiple project identifiers to resolve to a single canonical project.

Schema Proposal

CREATE TABLE project_aliases (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    project TEXT NOT NULL,           -- canonical project name
    alias TEXT NOT NULL,              -- alias or git_url
    type TEXT NOT NULL DEFAULT 'alias',  -- 'alias' | 'git_url'
    created_at TEXT NOT NULL DEFAULT datetime('now')
);

Behavior

1. Alias matching: When a project name is detected, check if it exists as an alias pointing to a canonical project
2. Git URL optional verification: Store git URLs as optional verification, not requirement
3. Backward compatible: If no alias matches, use the detected name as-is (current behavior)
4. Cross-alias search: When searching/filtering by project, automatically include all aliases

CLI Usage

# List all aliases
engram aliases list

# List aliases for specific project
engram aliases list --project myapp

# Add alias
engram aliases add myapp myapp-installer

# Add git_url for verification
engram aliases add myapp https://github.com/user/myapp.git --type git_url

# Remove alias
engram aliases remove myapp-installer

HTTP API

GET  /projects/aliases                    # List all aliases grouped by project
GET  /projects/aliases?project=myapp      # List aliases for specific project
POST /projects/aliases                    # Add alias {"project": "...", "alias": "...", "type": "alias|git_url"}
DELETE /projects/aliases/{alias}          # Remove alias

Key Functions

• ResolveProject(name) - resolves alias to canonical project
• GetProjectAndAliases(name) - returns canonical + all aliases (for IN queries)
• Modified RecentObservations, RecentSessions, Search to search across aliases

📦 Affected Area

• Store (database, queries)
• CLI (commands, flags)
• HTTP Server (API endpoints)

📎 Additional Context

This enables workflows like:

• Grouping "myapp", "myapp-installer", "myapp-docs" under one project
• Worktree support by allowing worktree paths as aliases
• Optional git URL verification for disambiguation without requiring git

[Alan-TheGentleman]

This is not implemented yet.

What is already solved is the worktree side of the problem through git-based project detection, and there is also a manual MigrateProject(old, new) path for destructive renames. But that is not the same thing as aliasing multiple related repos under one logical project.

What remains open here is the actual aliasing model: schema, alias-aware query resolution, and how that should behave across CLI, HTTP, MCP, and sync.

So this issue should stay open, but it should be treated as design work first, not assumed done.