fix: honor memory scope filters during recall

[DevChiniwala]

Summary

memory_recall accepts scope_filter to limit which memory scopes contribute, but the filter could be bypassed by MemoryService default-profile fallback.

When a caller requested global-only recall, the tool cleared the profile before calling the service. MemoryService.recall() then replaced the falsey profile with its default profile, returning profile-scoped evidence that the caller explicitly excluded.

Fix

• Thread scope_filter through the memory tool to MemoryService.recall().
• Apply the filter before default-profile fallback so excluded profile/session scopes remain excluded.
• Add a deterministic SQLite regression covering global, profile, and session memories through the public memory_recall tool handler.

No storage schema, response shape, or provider API changes.

Validation

• Regression: passes after the fix; fails before it with 2 results instead of 1.
• Memory tests: 18 passed.
• Full offline pytest: 226 passed, 5 skipped.
• python -m compileall -q datamind: passed.
• SQLite verification demo: passed.
• No paid or live LLM APIs used.

The five skipped tests are optional claude_agent_sdk hook tests.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[haolpku]

Requesting changes because the implementation does not fully honor scope_filter. MemoryService only clears profile/session IDs; the SQLite store still includes global memories unconditionally. Therefore scope_filter=['profile'] and ['session'] can still return global items, and [] falls back to all scopes. Please carry an explicit allowed-scope set through the service/store (or filter before returning), define the empty-list behavior, and add tests for global-only, profile-only, session-only, combinations, and empty input.