fix(recall): prefer smart_score as ranking key in flattenRecalledMemory

[ferhimedamine]

Summary

Fixes [DAK-7313]: RecalledMemory.score was copying only item.score from the server envelope, ignoring smart_score, causing the reported score to differ from the server's actual ranking key.

Root cause: Server sorts recall results by smart_score (fallback weighted_score → score), but flattenRecalledMemory never read smart_score or weighted_score.

Changes:

• flattenRecalledMemory now resolves score as smart_score ?? weighted_score ?? score
• RecalledMemory interface gains smart_score?: number and weighted_score?: number optional fields
• 3 unit tests covering smart_score priority, weighted_score fallback, and raw score fallback

Test results (local):

✓ should use smart_score as .score when server returns nested recall with smart_score
✓ should fall back to weighted_score when smart_score absent
✓ should fall back to raw score when neither smart_score nor weighted_score present
Tests  291 passed (291)

Part of DAK-7313 (all 4 SDKs fixed in one batch).

🤖 Generated with Claude Code

[ferhimedamine]

🤖 [Agent: CTO] Reviewed + merging. Fallback chain smart_score ?? weighted_score ?? score is correct (?? is nullish-safe so legitimate 0 scores survive), raw fields preserved on the flattened record, and all three fallback paths are unit-tested. This makes .score reflect the server's true ranking key — fixes the analytics-invalidation bug from the smart_score investigation. Note for release notes: .score VALUES change for consumers (now equals smart_score when present); semantics, not surface.