feat: add memory access tracking to improve Auto Dream cleanup decisions

Problem

When auto memory approaches the 200-line MEMORY.md limit, there is no data-driven way to decide which memories to keep and which to prune. Users must manually audit memory files with no visibility into actual usage patterns across sessions.

More critically, low frequency ≠ unnecessary — but without access data, this distinction is impossible to make. Some memories are rarely triggered yet prevent costly mistakes (safety rules), while others haven't been referenced in months and are safe to remove (internalized knowledge).

Current Behavior

Auto Dream consolidates memory using structural heuristics only:

• Duplicate detection
• Stale reference removal (deleted files/patterns)
• Related note merging

These heuristics cannot distinguish between:

| Memory Type | Frequency | Value | Correct Action |
|-------------|-----------|-------|----------------|
| Safety rule (e.g., "never commit binaries") | ~3x/month | High — prevents recurring mistakes | Keep |
| One-time debugging note (e.g., "PR #630 review") | 0x in 3 months | Low — already internalized | Archive/Remove |

Both appear "stale" by structural analysis alone. Without access frequency data, Dream has no signal to differentiate them.

Proposed Value

Tracking minimal access metadata per memory file — specifically access_count and last_accessed_date — would:

1. Improve Auto Dream's cleanup quality: Dream gains usage-pattern signals alongside structural heuristics, enabling smarter keep/prune decisions for the memories that structural analysis alone can't evaluate
2. Enable "low-frequency ≠ unnecessary" distinction: A safety rule accessed 3x/month is clearly valuable despite low frequency; a debugging note with 0 accesses in 3 months is safe to archive
3. Support user-driven auditing: When approaching the 200-line limit, users can identify truly unused memories vs. rarely-but-importantly-used ones

Concrete Example

feedback_atomic_commit.md    — 47 hits, last: 2 days ago   → Keep (active use)
feedback_no_binary_commit.md — 3 hits/month, last: 5 days  → Keep (safety rule, low freq but high value)
project_pr630_review.md      — 0 hits, last: 3 months ago  → Safe to archive

Evidence

Personal Experience

• Active Claude Code user with 228-line MEMORY.md (exceeding the 200-line display limit)
• Regularly face difficulty deciding which memories to prune during manual audits
• Critical safety-rule memories (preventing production incidents) appear "stale" by date alone but are among the most valuable entries
• Auto Dream's structural consolidation helps with duplicates but cannot make value judgments about usage patterns

Community Context

No existing issues propose access tracking or memory analytics — this appears to be a novel approach. However, several open issues reflect the broader need for better memory governance:

• #25006 — MEMORY.md 200-line hard limit is undocumented; users hit it unexpectedly
• #40614 — Hierarchical memory to prevent silent loss at the 200-line limit
• #40210 — Newest memories lost first due to truncation direction (bug)
• #38493 — Auto-dream gaps in accuracy and transparency
• #34776 — Memory system governance for long-running users
• #27298 — Layered memory system for persistent cross-session context (18 comments)

Access tracking would complement these efforts by providing the data layer that governance policies and Dream improvements can build upon.

Future Scope

This proposal focuses narrowly on access tracking as a foundational data layer. Potential follow-up proposals that could build on this data:

• Dream Report: Post-consolidation summary showing what Dream changed and why (transparency)
• Retention Policy: User-configurable cleanup rules informed by access data (e.g., "archive if 0 hits in 90 days, but never auto-remove feedback-type memories")
• Effectiveness Signal: Whether a memory actually changed agent behavior (prevented a mistake vs. was loaded but had no observable impact)

Each of these would be a separate proposal. This issue intentionally leaves implementation details open — the goal is to validate the problem and proposed value with the community and maintainers.