Feature: opt-in per-worktree memory isolation

Problem

When using git worktrees for concurrent parallel development (e.g. two open tickets in two tmux panes, each in its own worktree), Claude Code's auto-memory system directs all worktrees to the same shared memory directory — the one derived from the git common dir (the main repo root).

This causes cross-worktree memory contamination. A concrete example: a file called active-ticket.md written by skill tooling in worktree A is immediately visible to and overwritten by the same skill running in worktree B. Since the memory directory is shared, any single-instance memory file (files with a fixed name rather than a per-ticket name) becomes a race condition across worktrees.

Observed behaviour:

• Session project directories are per-worktree: ~/.claude/projects/-…-feature-A/ and ~/.claude/projects/-…-feature-B/ exist separately (sessions are isolated).
• The memory/ subdirectory only exists under the git-root project dir (~/.claude/projects/-…-main-repo/memory/), and the system prompt injected into all worktree sessions points there.

This is the inverse of #34437, which requests that session history be shared across worktrees. Both needs are valid — they're different use cases.

The real need: two tiers of memory

Not all memories should behave the same way. Within a single repo, there are two distinct categories:

Repo-scoped (shared across all worktrees) — these should remain visible everywhere:

• Feedback and preference memories (coding style, response format preferences)
• Reference memories (where to find things: Jira project keys, Grafana dashboards, team norms)
• Completed-ticket project summaries (historical, read-only context)

Worktree-scoped (isolated per worktree) — these track current, mutable state:

• Active ticket pointer (active-ticket.md or equivalent)
• In-progress ticket context (to-do file path, plan path, design doc path)
• Any memory that a skill writes during an active work session

A binary "scope": "repo" | "worktree" setting would force a choice between the two, losing one or the other. What's actually needed is the ability to place a memory file in either tier.

Proposed Solution

Introduce a two-directory memory model for worktrees:

1. Shared memory — ~/.claude/projects/-…-main-repo/memory/ (current directory, unchanged). Repo-scoped memories live here and are visible to all worktrees.
2. Worktree memory — ~/.claude/projects/-…-feature-A/memory/ (new, per worktree). Worktree-scoped memories live here and are invisible to other worktrees.

When Claude Code injects the memory path into the system prompt for a worktree session, it could inject both paths — one labelled "shared (repo-wide)" and one labelled "worktree-specific" — so the model knows which directory to write to based on the nature of the memory being saved.

Alternatively, a frontmatter field in memory files could declare scope:

---
name: active-ticket
scope: worktree   # "repo" (default) | "worktree"
---

Files marked scope: worktree would be written to and read from the worktree-specific directory; all others continue to use the shared directory.

Use case

Teams using worktrees for parallel ticket development — e.g. one session per open ticket, each in its own tmux pane — need in-progress ticket state to be isolated per worktree, while still benefiting from shared feedback, preferences, and reference memories that apply across the whole repo.