DELETE /api/v1/memories does not cascade to derived memories (episodic, foresight, event_log)

[contextablemark]

Summary

DELETE /api/v1/memories soft-deletes MemCell documents in MongoDB but does not cascade to derived memory types. After deletion, episodic_memory, foresight_record, and event_log_record documents remain in MongoDB, Elasticsearch, and Milvus — and continue to appear in search results.

Steps to Reproduce

1. Store messages via POST /api/v1/memories until boundary detection triggers extraction
2. Confirm episodic memories are searchable via GET /api/v1/memories/search
3. Delete the MemCell: DELETE /api/v1/memories with event_id set to the MemCell _id
4. Search again — derived memories still appear

Expected Behavior

Deleting a MemCell should cascade to all derived records:

• episodic_memories — delete from MongoDB, Elasticsearch, and Milvus
• foresight_records — delete from MongoDB and Milvus
• event_log_records — delete from MongoDB, Elasticsearch, and Milvus

The repository classes already have the necessary delete methods (EpisodicMemoryEsRepository.delete_by_event_id, ForesightMilvusRepository.delete_by_parent_id, etc.) — they just aren't called from MemCellDeleteService.delete_by_combined_criteria.

Actual Behavior

MemCellDeleteService.delete_by_combined_criteria only calls MemCell.delete_many(filter_dict). No derived memories are touched. The cascade delete infrastructure (repository delete methods) exists but is not wired into the delete service.

Additional Context

• Related to [Feature Request] Add APIs for Deleting/Resetting Memories to Support Chat Editing and Context Clearing #14 (feature request for delete APIs) and Memory write pipeline: add deduplication for episodic/event_log and expiry cleanup for foresight #95 (dedup/cleanup)
• The memcell_event_id_list field on derived memories provides the link back to the parent MemCell, which could be used for cascade lookups
• Tested on commit 3c9a2d0246