Feature: Memory Privacy Center with Retention, Redaction, and Export Controls

## Summary

Add a Memory Privacy Center that lets users inspect, export, redact, expire, and delete Forge's local memory and conversation data across hot, warm, cold, and learning layers from a consistent CLI and dashboard workflow.

## Problem / Opportunity

Forge is local-first and intentionally stores useful working context in sessions, conversations, SQLite indexes, cold memory, and learning patterns. That is powerful, but users need a first-class way to answer practical questions before sharing a machine, switching projects, debugging an agent decision, or preparing a repo for handoff:

- What has Forge remembered about this project?
- Which memories came from user input, files, tool results, or model output?
- Which entries contain secrets or sensitive paths after redaction?
- What can be exported for audit, and what can be safely deleted without corrupting task history?
- Which retention policy applies to each memory layer?

Today the CLI exposes memory commands such as indexing, search, pruning, decay, and clearing learning memory, but there is no unified privacy-oriented control surface with provenance, dry-run deletion, redaction review, or export reports.

## Proposed Feature

Build a privacy and retention workflow spanning CLI, persistence, memory, security, and dashboard surfaces:

- Add `forge memory privacy` commands for summary, inspect, export, redact, and delete flows.
- Show per-layer inventory counts, storage paths, byte sizes, last-updated timestamps, and retention status.
- Surface provenance for entries where available: conversation turn, task id, source file, tool result, or learning pattern.
- Run existing secret redaction rules over exported reports and provide a dry-run mode before destructive cleanup.
- Support retention policies for each memory layer in project/global config, with documented defaults and explicit overrides.
- Add a dashboard view for inspecting memory inventory, filtering by source/layer/date, exporting a redacted report, and confirming cleanup actions.

## Scope

- CLI commands under the existing `memory` command group.
- Config schema additions for memory retention and export behavior.
- Memory layer adapters for hot, warm, cold, and learning stores.
- Redaction integration through the existing security redaction module.
- Dashboard API endpoints and UI for inventory/export/delete workflows.
- Documentation updates in README, CLI reference, setup docs, and privacy/security notes.
- Unit tests for inventory generation, redaction behavior, retention filtering, dry-run deletion, and config parsing.

## Acceptance Criteria

- [ ] `forge memory privacy summary` reports all memory layers with counts, paths, sizes, retention policy, and last-updated time.
- [ ] `forge memory privacy inspect --layer ` lists entries with stable ids, provenance where available, and redacted previews.
- [ ] `forge memory privacy export --format json|md` writes a redacted audit report without leaking known secret patterns.
- [ ] `forge memory privacy delete --dry-run` reports exactly what would be removed before any mutation occurs.
- [ ] Destructive delete/redact operations require the same permission discipline as other mutating Forge operations.
- [ ] Dashboard users can review the same inventory and trigger export/dry-run cleanup without reading raw storage files.
- [ ] Retention settings are documented, validated, and covered by tests.
- [ ] Existing memory commands continue to work unchanged.

## Non-Goals

- Cloud sync or remote backup of memory data.
- Replacing the current hot/warm/cold/learning memory architecture.
- Building a generic database browser for all Forge persistence internals.
- Perfect PII detection beyond the redaction rules Forge already supports or explicitly adds for this feature.

## Dependencies / Risks

- The implementation must not corrupt append-only conversation or session JSONL files.
- Retention cleanup must distinguish derived indexes from source records so users can safely rebuild cold memory.
- Redaction previews must avoid logging sensitive values while still giving enough context to be useful.
- Dashboard mutation endpoints must preserve the project's permission and sandbox posture.

## Open Questions

- Should retention defaults apply globally, per project, or both with project overrides?
- Should exports include raw task/session identifiers by default, or hash them for privacy?
- Should the first version support only JSON and Markdown, or also CSV for inventory reporting?