Add local controlled memory management UI

[elinawang626-design]

Summary

• add a local controlled-memory provider that works without remote memU configuration
• expose memory control APIs through IPC and preload for pause/resume, manual remember, suppression, edit/delete, history, and retrieval explanations
• add a settings UI for inspecting and managing local memory entries, including provenance, retention, conflict state, and retrieval reasons
• fall back to local controlled memory retrieval when remote memU is not configured

Why

This complements the existing memory fallback work by making local memory usable and inspectable from the product layer. It gives users direct control over what is stored locally and what can be retrieved, without requiring cloud memory services.

Relationship To #33

• #33 is a narrow hardening PR for retrieval correctness and topic-scoring fallbacks
• this PR is the larger product-surface PR that exposes local controlled-memory capabilities end to end
• the two PRs are complementary, but intentionally separate so the smaller fallback fix can be reviewed and merged independently
• this PR does not supersede #33; it builds out the broader local-memory management surface

Included functionality

• pause / resume local memory capture
• manually remember an item
• mark content as "don't remember"
• filterable local memory list
• provenance / why stored / retention / conflict display
• "Why this memory was retrieved" explanation display
• single-item edit / delete
• bulk delete by source
• memory history view

Scope

This PR is intentionally scoped as a complete local controlled-memory management surface, so it includes:

• backend provider and storage changes
• IPC and preload bridge changes
• settings UI changes

It intentionally excludes unrelated notes and package metadata changes that existed in my fork.

Reviewer Notes

• the main review question here is whether memU should support a fully local, user-controllable memory-management path in the product surface
• the backend and UI are included together because the UI depends on the new local memory control APIs
• I left this PR as draft to make it easier to discuss scope and desired split before asking for final review

Validation

• npm run typecheck
• manually verified the intended surface on this branch: pause/resume, remember-this, don't-remember, filtered list view, retrieval explanation, single-item edit/delete, delete-by-source, and memory history
• verified branch is based on upstream/main and excludes unrelated notes / package metadata changes

Risks / Tradeoffs

• this is materially larger than #33, so I expect review attention to focus on scope and product fit more than on individual line changes
• there may still be unrelated upstream failures outside this branch's changed paths; this PR is not intended to fix those existing issues

[elinawang626-design]

Context for reviewers: this PR is intentionally separate from #33.

• Harden memu retrieval and topic scoring fallbacks #33 is the small hardening PR for retrieval correctness and topic-scoring fallback behavior.
• Add local controlled memory management UI #34 is the broader local controlled-memory management surface: backend + IPC/preload + settings UI.
• I kept Add local controlled memory management UI #34 as a draft because the main question here is scope/product fit rather than whether it should be bundled with the narrower fallback fix.

If it would help review, I can further split this into a backend/API PR and a follow-up UI PR, but in the current branch the UI depends on the local memory control surface added here.