Fix: /memory/ingest hardcodes source_mode=chat, partially defeats #877 partition

[mimeding]

Summary

Why this matters (business)

PR osaurus-ai#877 introduced one of the more important UX guarantees in the memory subsystem: facts learned while an agent had tools available (Work mode, sandbox, etc.) should not seep back into pure-chat sessions and make the model believe it has tools it doesn't. Without that partition, agents in chat-only mode confidently reference file paths, sandbox commands, and other agentic affordances that won't actually work for the user.

The HTTP ingest endpoint — which is the path users hit for:

• seeding memory from existing chat logs,
• migrating from another assistant,
• bulk-loading conversations for offline benchmarking (LoCoMo runs use this exactly),
• programmatic admin tooling,

was tagging every ingested turn as pure .chat, regardless of what mode produced the source data. Tool-flavoured turns therefore landed in the partition that chat-only recall reads from, and the recent partition guarantee silently degraded the moment a real batch was loaded.

This is the kind of regression that doesn't surface in unit tests but shows up as "the agent keeps offering to run shell commands when I never enabled tools" in user reports.

What's wrong (technical)

                    try? db.insertChunk(
                        ...
                        sourceMode: .chat
                    )
                    ...
                        sourceMode: .chat,

Both the chunk insert and the recordConversationTurn call hardcoded .chat. MemorySourceMode is already Codable (see Work/WorkExecutionMode.swift:38), and both downstream APIs already accept an optional MemorySourceMode parameter — only the HTTP request decoder was missing the field.

Fix

Add two optional fields to MemoryIngestRequest:

1. source_mode — batch-level default applied to every turn that does not override it.
2. source_mode on MemoryIngestTurn — per-turn override for migrated logs that mix modes.

Both default to .chat, so existing callers (and the example in docs/MEMORY.md) are byte-identical. Tagging now flows correctly through db.insertChunk and MemoryService.recordConversationTurn.

Also:

• Updated the validation error string to reflect the new fields, so misformatted requests get a useful hint.
• Updated docs/MEMORY.md parameter table with the new fields and a one-line note on why tagging matters.

Changes

• Behavior change (additive — default unchanged)
• UI change
• Refactor / chore
• Tests (no HTTP-handler integration harness for /memory/ingest; downstream insertChunk(sourceMode:) already has coverage in MemoryDatabaseTests)
• Docs (docs/MEMORY.md updated)

Test Plan

1. Default behavior unchanged:

   curl http://127.0.0.1:1337/memory/ingest -H 'Content-Type: application/json' \
     -d '{"agent_id":"a","conversation_id":"c","turns":[{"user":"hi","assistant":"hello"}]}'

   Inspect the resulting conversation_chunks row — source_mode = 'chat' as before.

2. Per-batch override:

   curl http://127.0.0.1:1337/memory/ingest -H 'Content-Type: application/json' \
     -d '{"agent_id":"a","conversation_id":"c2","source_mode":"work_host",
          "turns":[{"user":"run ls","assistant":"file1\nfile2"}]}'

   source_mode = 'work_host' on every chunk. Open the agent in pure-chat mode and confirm via Insights that those rows are filtered out of chatOnly recall.

3. Per-turn override:

   curl http://127.0.0.1:1337/memory/ingest -H 'Content-Type: application/json' \
     -d '{"agent_id":"a","conversation_id":"c3","source_mode":"chat",
          "turns":[
            {"user":"hi","assistant":"hello"},
            {"user":"sandbox","assistant":"$ ls","source_mode":"chat_sandbox"}
          ]}'

   First chunk pair tagged chat, second tagged chat_sandbox.

Checklist

• I have read CONTRIBUTING.md
• I added/updated tests where reasonable (see test plan; downstream layers already covered)
• I updated docs/README as needed
• I verified build on macOS with Xcode 16.4+ (authored in a Linux CI sandbox)