Feature request: user-level (cross-project) scope for auto-memory

Feature request

Add a user-level (cross-project) scope for auto-memory, alongside the existing per-repository scope.

Problem

Auto-memory is currently strictly per-repository (~/.claude/projects/<project>/memory/). This is right for project facts, but a class of knowledge is inherently cross-project: operational runbooks (VPN reconnect, AWS SSO login, ArgoCD login), tooling conventions, infra triage procedures. Today that knowledge only exists in whichever project's memory the session happened to save it to.

Concrete case: my agent saved detailed self-recovery runbooks (corporate VPN via openfortivpn, aws sso login, argocd re-auth) into one project's memory. In a session in a different repo, the cluster connection dropped three times — the agent correctly diagnosed the VPN each time but couldn't act, because the runbooks lived in another project's memory directory and never loaded. Same machine, same user, same infrastructure — knowledge stranded by project boundary.

Proposal

Add a user-scope memory directory (e.g. ~/.claude/memory/) with its own MEMORY.md index, loaded into context alongside the project index in every session. The existing memory frontmatter already distinguishes type: user | project | reference — user/reference memories are natural candidates for the user scope, and the agent could choose the scope at save time ("this fact is machine/user-wide, not repo-specific").

Workarounds considered and why they fall short

• @import in ~/.claude/CLAUDE.md loads the full content in every session of every project — pays the token cost always for knowledge needed rarely, and loses the index/recall-on-demand semantics that make auto-memory efficient.
• Manual pointer paragraphs in memory files or CLAUDE.md work but are easy to forget in new projects and rot as paths change.
• Copying memory files between project directories diverges immediately.

The index-plus-lazy-read model auto-memory already has is exactly what cross-project knowledge needs — it just needs one more scope.