[bug] Daily memory editor opens wrong source when multiple memories share a date

[lyrishark]

Memory editor opens the wrong daily memory when multiple sources share a date

Summary

Daily memory files can coexist for the same date with different source instances, for example:

• 2026-06-12_entity-loom.md
• 2026-06-12_psycheros.md

The memories list displays both entries, but each list row links to the editor by date only:

/fragments/settings/memories/daily/2026-06-12

Because memory_read falls back to a date-only lookup, clicking either row can open the first matching file rather than the selected source-specific file.

Impact

• The settings UI can show two same-day daily memories but open only one of them.
• Editing/saving from that view risks updating the wrong source-specific memory.
• Any downstream feature that lists memories and then reads by date can accidentally read the wrong same-day source. In our local browser-extension memory injection endpoint, this made receiver-platform filtering inspect the entity-loom/ChatGPT-imported memory when it meant to inspect the Psycheros memory for the same date.

Reproduction

1. Create or import at least two daily memories for the same date with different source instances, such as entity-loom and psycheros.
2. Open Settings -> Memories -> Daily.
3. Click each same-date row.
4. Both rows can open the same editor content, because the source instance is not included in the fragment request.

Root Cause

memory_list already returns sourceInstance, but the UI drops it when building the editor link. The server then calls readMemory(granularity, date) without a source selector, so entity-core uses the compatibility date-only lookup.

Proposed Fix

Carry the source instance through the full read/edit path:

• Add optional sourceInstance to memory_read.
• Teach createMemoryReadHandler to call FileStore.readMemory(granularity, date, sourceInstance) when present.
• Add optional instanceId and slug passthrough to memory_update so save operations can target the same source-specific file.
• In the settings memory list, append ?sourceInstance=... to daily memory editor links when the listed item has a source instance.
• Pass the request URL into handleMemoriesEditorFragment, parse and validate sourceInstance, and use it for readMemory.
• Add the same query parameter to the editor form hx-post, then pass it through to updateMemory.
• Render a visible label like 2026-06-12 (psycheros) so duplicate dates are distinguishable.

Local Patch Status

Patched locally in:

• packages/entity-core/src/tools/memory.ts
• packages/entity-core/src/server.ts
• packages/psycheros/src/mcp-client/mod.ts
• packages/psycheros/src/server/routes.ts
• packages/psycheros/src/server/server.ts
• packages/psycheros/src/server/templates.ts

The installed AppData source was patched and the daemon was restarted so the running app could be verified locally.

Verification

Against the live local app on port 3000:

• GET /fragments/settings/memories/daily?after=2026-06-12&before=2026-06-12 now returns distinct row links:
  • /fragments/settings/memories/daily/2026-06-12?sourceInstance=entity-loom
  • /fragments/settings/memories/daily/2026-06-12?sourceInstance=psycheros
• GET /fragments/settings/memories/daily/2026-06-12?sourceInstance=psycheros opens the Psycheros memory and shows Source: psycheros.
• GET /fragments/settings/memories/daily/2026-06-12?sourceInstance=entity-loom opens the imported memory and shows Source: entity-loom.
• The editor save form now posts to /api/memories/daily/2026-06-12?sourceInstance=psycheros for the Psycheros row.

deno check passed for the patched files in the fork. The installed AppData source still reports unrelated pre-existing type errors around BLE/custom-tools route signatures.