Feature/data portability export import

[SiddheshCodes4554]

This PR adds a built-in data portability flow so users can back up, migrate, and restore their memories directly from the web app. The goal is to give users better control over their long-term memory data without needing external scripts or manual database access.

What’s included

• Export memories as JSON.
• Export memories as Markdown.
• Filter exports by container tags.
• Filter exports by date range.
• Import previously exported JSON archives.
• Add a dedicated Data portability section under Settings.

How it works

The web app now exposes authenticated memory export/import routes that proxy through the existing backend API using the same session/auth context as the rest of the app.

For export:

• The route fetches paginated memory documents from the backend.
• JSON exports include metadata and document records.
• Markdown exports render a human-readable archive with headings, timestamps, tags, and content sections.

For import:

• The route accepts previously exported JSON payloads.
• It validates and normalizes the payload before sending it to the backend in batches.
• Imported memories can preserve content, metadata, custom IDs, and tags where available.
• The UI lets users upload a JSON backup and receive feedback on success or failure.

UI changes

A new Settings panel was added for:

• Choosing export format.
• Filtering by date range.
• Filtering by tags.
• Downloading the exported archive.
• Uploading a JSON backup for restore.

Why this change

Many users use supermemory as a long-term memory store for AI workflows. A portability workflow makes it easier to:

• Migrate between environments.
• Keep backups for recovery.
• Archive personal knowledge.
• Increase transparency and user trust.

[ishaanxgupta]

This PR includes an unrelated change to packages/pipecat-sdk-python/src/supermemory_pipecat/service.py plus a new Pipecat empty-profile test. That change is outside the data-portability/export-import scope and overlaps with other open Pipecat PRs for the same bug, so it should be removed from this PR (or split into its own dedicated PR) before review. Keeping it here makes the portability feature harder to evaluate and risks merging unrelated SDK behavior through a web settings change.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f5bff0b332

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Filter exported memory entries by selected tags

When containerTags is provided, this serializes the documents returned by /v3/documents/documents as-is, including every memoryEntries item on each matching document. Existing graph code has to filter those entries by spaceContainerTag for the selected tags (apps/web/components/memory-graph/hooks/use-graph-api.ts:90-96), so a document that has memories in multiple spaces will export entries from spaces the user did not select; the markdown path builds from the same unfiltered list as well.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Preserve tag filters when importing panel exports

For JSON produced by this export route with a tag filter, the selected tags are stored under filters.containerTags, but the import mapping only falls back to document.containerTags when no top-level override exists. Since the documents-with-memories schema used by the export endpoint does not include document-level containerTags, importing a filtered backup recreates those memories without the space tags the user exported from, breaking the advertised round-trip restore for tagged archives.

Useful? React with 👍 / 👎.