fix: strip profile embedding vectors from memory tool output and profile API

[share121]

Summary

Each profile item persists two 768-dimension embeddings (centroid and anchor) that are only used internally for similarity, dedup and drift detection. Both the memory tool's profile mode and GET /api/user-profile serialized the raw profileData, so they shipped those vectors to callers. A populated profile (18 items: 8 preferences + 8 patterns + 2 workflows) serialized to ~591 KB, which exceeded the tool-output limit and got truncated — the profile result was unusable and burned model context (observed as a truncated ~594 KB tool response).

This change strips centroid/anchor from serialized profile data. The vectors are still stored and used internally; they are only removed from what leaves the process.

Changes

• src/services/user-profile/profile-utils.ts: add stripProfileEmbeddings(data) that deletes centroid/anchor from every item in preferences/patterns/workflows.
• src/index.ts: apply it to the profile read branch of the memory tool.
• src/services/api-handlers.ts (handleGetUserProfile): apply it to the API response that feeds the Web UI.
• tests/profile-utils.test.ts: cover stripping across all three item types plus missing/malformed sections.

Testing

• bun test tests/profile-utils.test.ts — 2 pass
• bunx tsc (build) — clean
• bun test — 465 pass / 2 fail; both failures are Windows-environment only and unrelated to this change:
  • tests/onnxruntime-resolve.test.ts — EPERM creating a symlink
  • tests/turso-legacy-migrator.test.ts — EBUSY unlinking a locked db file
• bunx prettier --check on the changed files — clean
• Manual: live profile payload 361,121 → 4,313 bytes after stripping; GET /api/user-profile returns 4,812 bytes with no centroid; memory search still returns the expected results.

Notes

• No behavior change other than response size; stored profile data is untouched.
• Observed locally on Windows, opencode-mem 2.26.0. No upstream issue was filed for this.