fix: correct memory_len in log_working_memory_replacement

[RerankerGuo]

Summary

This PR fixes #1790 by correcting the memory_len field logged by log_working_memory_replacement in src/memos/mem_scheduler/general_modules/scheduler_logger.py.

Changes

• Changed memory_len=len(memcube_content) → memory_len=len(new_memory).
• memcube_content only contained the newly added memories (delta), which caused the scheduler UI to display the count of changes rather than the total working-memory size.
• len(new_memory) reflects the total number of memories in the working memory after replacement — consistent with how other log entries represent the output size.
• Removed the stale # TODO: Log output count is incorrect comment, since the underlying issue is resolved.

Example

• Original working memory: [A, B, C] (3 items)
• New working memory: [A, B, D] (3 items)
• Before fix: memory_len = 1 (delta — only D was added)
• After fix: memory_len = 3 (total output size)

Testing

• python3 -m py_compile src/memos/mem_scheduler/general_modules/scheduler_logger.py passes
• No behavior / API / schema change — log field only
• Followed existing code style, single-line, minimal change

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• The change is minimal and non-breaking
• Linked the issue to this PR (Closes fix: log_working_memory_replacement reports incorrect memory_len (delta instead of total) #1790)

[Memtensor-AI]

🤖 Open Code Review

Target: PR #2176
Task: 5596263aad127f17
Base: main
Head: fix/issue-1790-working-memory-len

🔍 OpenCodeReview found 1 issue(s) in this PR.

---

1. src/memos/mem_scheduler/general_modules/scheduler_logger.py (L229)

Semantic mismatch: memory_len now reflects the total size of new_memory (all working memory items after replacement, including pre-existing ones), but memcube_log_content (the field passed as memcube_log_content=memcube_content) contains only the newly added items. Log consumers that use memory_len to understand the count of changes captured in this event will get an inflated, unrelated number.

Furthermore, the parallel method log_activation_memory_update uses memory_len=len(added_memories) (count of newly added items), creating an inconsistency in how memory_len is interpreted across the two log methods.

If the intent is to record the total working memory size after replacement, rename the field at the call site (e.g., via a dedicated argument or comment) so consumers can distinguish it from a change-count. If the intent is to count changed entries consistent with memcube_log_content, revert to len(memcube_content).

💡 Suggested Change

Before:

                memory_len=len(new_memory),

After:

                # Use len(memcube_content) to stay consistent with memcube_log_content
                # and with how log_activation_memory_update computes memory_len.
                # Use len(new_memory) only if the intent is to report total working memory size.
                memory_len=len(memcube_content),

Generated by cloud-assistant via Open Code Review.

[Memtensor-AI]

✅ Automated Test Results: PASSED

All tests passed (2/2 executed). memos_python_core/changed-python-source: 2/2. Duration: 4s [advisory, non-gating] AI-generated tests on branch test/auto-gen-5596263aad127f17-20260730085853: 30/30 passed — these do NOT affect the PR verdict; review the branch manually.

Branch: fix/issue-1790-working-memory-len