Feature/project registry cli

[hanley-development]

Summary

Adds an optional local project registry and CLI commands for managing multiple ProjectMem projects from one installation.

The registry lets users register project directories, assign aliases and tags, select an active project, and resolve projects consistently across commands. Existing project-local workflows remain supported.

What changed

• Added versioned project registry persistence at:
  • $PROJECTMEM_HOME/projects.json
  • ~/.projectmem/projects.json by default
• Added project registration, removal, listing, inspection, detection, and active-project selection.
• Added project aliases, brain assignments, and tags.
• Added pjm project CLI commands for managing the registry.
• Added support for preregistering an existing directory with --allow-uninitialized.
• Added canonical path and strict registry-data validation.
• Added actionable CLI errors for missing or invalid projects.
• Documented registry usage in README.md and TUTORIAL.md.
• Documented the registry’s local data and security boundaries in SECURITY.md.

Compatibility

• Existing projects do not need to use the global registry.
• Normal registration requires an initialized .projectmem/ directory.
• --allow-uninitialized may be used to preregister another existing directory.
• Registry data remains local-only.
• No telemetry or network transfer was added.
• Existing public function signatures and CLI entry points remain unchanged.

Validation

• Focused registry and CLI tests: 43 passed
• Full test suite: 177 passed, 1 skipped
• Ruff: passed
• Git whitespace check: passed
• Independent code review: no remaining Critical or Important findings

Scope

This PR contains only the project registry and project management CLI feature, its tests, review fixes, and related documentation.

Base branch: main
Feature branch: feature/project-registry-cli
Dependencies on other feature branches: none

[riponcm]

Hi Mike — this is really well done. Atomic writes, versioned schema, strict validation, and strong test coverage — exactly the quality I want here. Thank you.

Two things to reconcile before I merge:

1. There's already a registry at the same path. v0.2.0 ships a small project registry at ~/.projectmem/projects.json, used by pjm dashboard (register_project / registered_projects in storage.py). But it stores a plain JSON list of absolute paths — ["/repo1", "/repo2"] — while yours stores a structured object. Right now load_registry() would reject that existing format, so on upgrade a user's pjm dashboard breaks and the two writers clobber each other's file.

Your structure is the one to keep — it's a superset and the right foundation for the global-MCP work. Could we make it the single registry by:

Auto-migrating the legacy list — when load_registry() sees a plain list of paths, convert each into a record instead of erroring.
Pointing the dashboard at the new registry — update registered_projects() in storage.py to read yours.
Keeping the current resilience — the existing reader silently skips stale/missing projects (a deleted repo shouldn't error). Let's preserve that.
2. Let's park the default_brain field for now — not drop the idea, just hold it. It's a nice thought, and I can see the use. But projectmem's scope today is coding + planning memory, so there isn't yet a coding-vs-personal distinction for it to capture. I'd rather keep the core minimal for now and bring brain back the moment a real user asks for personal memory — and since your schema already has schema_version, adding it later is a clean, non-breaking change. So nothing's lost by waiting.

Once those are in, I'll merge — and this becomes the shared foundation for the rest of the series. Really appreciate the care you put into this.