feat(memory): add secure user-owned memory store

[delkc]

Summary

Add the secure, user-owned foundation for Berd Memory.

• Store approved memory in readable ~/.me/me.md and ~/.me/topics/*.md files
• Respect the shared policy.json switch and deliver approved memory to supported agent sessions
• Publish a managed projection to ~/.agents/AGENTS.md without changing unrelated content
• Scope renderer writes to ~/.me, reject symlink/path escapes, and fail closed on unapproved external edits
• Share approved-content hashing and credential detection through the Rust memory core

Related issue

N/A. Bottom PR in the Memory stack.

Testing

• TypeScript typecheck, i18n, Biome, and design-system checks
• Memory preamble, publication, topic, policy, and credential tests
• Rust memory store and shared-core tests

Generated with Goose

[shellz-n-stuff]

A few issues here:

1. Why not store this encrypted with secret material in the keychain. That way it's only ever in memory cleartext rather than on disk (you can create a UI for users to edit memories manually too if you wanted)
2. The secret detection here is pretty naive. You may want to use something industry standard. Something like Titus would likely work nicely here.

[daveh-beep]

🤖 Drafted by my agent and reviewed by me.

@delkc I think we can address the security concerns without changing memory into a Berd-owned encrypted store.

• Agent-inferred facts require explicit approval before becoming memory. This prevents poisoned conversations or agents from silently planting durable content.
• Proposals are generated only from the person’s own messages—not agent responses, tool output, retrieved content, or attachments. This blocks untrusted external content from entering the memory pipeline.
• Recalled memory is treated as untrusted context, never as instructions or authorization. It cannot grant permissions, override current instructions, or independently authorize sending, publishing, shell execution, disclosure, or other external actions.
• Credentials and authentication material are rejected. Passwords, API keys, access tokens, recovery codes, and similar content cannot enter proposals or approved memory.
• Memory is not automatically projected into AGENTS.md or shared with other tools. Any widening of its audience requires a separate, deliberate choice.
• Memory is opt-in, and off is enforced by the memory service for running and future sessions. Disabled memory cannot be recalled and cannot accept new proposals.
• The person can inspect, edit, remove, disable, and delete memory directly. This makes poisoned or incorrect entries visible and removable without relying on Berd.
• Tests cover the specific threat: external content cannot become memory, unapproved proposals cannot be recalled, memory cannot authorize actions, and disabling memory stops access immediately.

This leaves one explicit boundary: local Markdown is not a secrets vault. It has the same local-access boundary as other user-owned files on the machine. These controls secure how agents create and use memory; they do not claim to protect files from every process already running with the person’s filesystem permissions.

Would this control set address the concern, or is protection from same-user local processes a required launch condition?