Problem

Auto Memory's private memory patch allowlist is broader than the documented
contract.

The code says private memory patches should target memory markdown files inside
the project memory directory, but the implementation currently allows any path
under config.storage.getProjectMemoryTempDir().

Relevant code:

• packages/core/src/commands/memory.ts
• packages/core/src/services/memoryPatchUtils.ts

The current flow is:

1. getAllowedMemoryPatchRoots(config, 'private') returns the full project
   memory temp directory.
2. resolveTargetWithinAllowedRoots() accepts any canonical path under that
   root.
3. listInboxMemoryPatches() and applyInboxMemoryPatch() therefore accept
   private patch targets that are inside the memory temp directory but are not
   actual memory markdown files.

Impact

A private memory patch can target files that should not be part of the memory
patch surface, including:

• .extraction-state.json
• .extraction.lock
• .inbox/*
• skills/*
• arbitrary non-markdown files under the project memory temp directory

This weakens the review boundary and does not match the extraction prompt or
comments around the private memory patch contract.

Expected Behavior

Private memory patches should only be able to target:

• the private project memory index, MEMORY.md
• approved sibling markdown files directly under the project memory directory

Private memory patches should reject:

• .inbox/
• skills/
• extraction state and lock files
• non-markdown files
• nested paths that are not part of the private memory document set

Acceptance Criteria

• Private memory patch validation rejects in-root but invalid targets.
• Tests cover attempts to patch .extraction-state.json, .inbox/*,
  skills/*, and non-markdown files.
• Existing valid flows for MEMORY.md and sibling *.md files still work.
• The implementation and comments agree on the exact allowed private memory
  patch target set.

Notes

This is a safety tightening issue rather than a request to change the overall
Auto Memory inbox model. The existing review-first design is good; the target
allowlist just needs to be narrower.