fix(cascade): scope LanceDB row ids by md path to stop cross-project overwrites

[alexmat]

Fixes #320.

Problem

Every daily-log cascade handler built LanceDB row ids as f"{owner_id}_{entry_id}", and user_profile as bare owner_id. Entry numbering is per-file (<kind>_<date>_NNNNNNNN), so any two projects with a same-date file produce identical row ids — and merge_insert("id") treats the previously indexed project's rows as matches and replaces them wholesale. Only the last-processed file per date survives.

Confirmed in production on 1.2.3 (current PyPI latest; main was still building ids the same way before this patch), in a multi-project deployment (~20 projects, one owner):

• The atomic_fact table stayed pinned at exactly 5,194 rows for 13+ hours while hundreds of commits landed — every insert was silently a replacement.
• Version-walk (list_versions + per-version counts) shows the mechanism in lockstep. One transition as the smoking gun: v2263 → v2264: −54 rows from project comms' atomic_fact-2026-08-27.md, +54 rows from project dsh-69826's same-date file, with identical entry_ids (af_20260827_00000018, …46, …19, …).
• The same scheme in user_profile (id = owner_id) collapsed 16 project profiles into 2 rows — the last two projects written.

Affected handlers: atomic_fact, episode, foresight, agent_case (all id=f"{owner_id}_{entry.entry_id}"), plus user_profile (id=owner_id).

Fix

Row id derives from the file's relative path plus entry id rather than enumerating scope keys — the path is unique by construction and stays correct if a new layout dimension appears later:

• Four daily-log kinds: id = f"{md_path}#{entry_id}"
• user_profile: id = md_path (of the user.md), with the recall-side profile fetch deriving the same path from app_id/project_id/owner_id (ProfileRecaller.fetch gains app_id/project_id params; call site in search/manager.py passes them from the request)

Regression test

tests/unit/test_memory/test_cascade/test_handler_row_id_project_scoping.py — parametrized over the four daily-log kinds: writes the same-date entry for two different projects through each writer + handler pair against an in-memory repo with merge-by-id semantics, and asserts both projects' rows coexist under distinct ids. Fails on ≤ 1.2.3 (4/4 fail), passes with this patch (4/4 pass).

Migration note for existing deployments

A full cascade rebuild is required after upgrading — sha-skip means old-id rows are never rewritten, and new-id rows would otherwise coexist as duplicates. Markdown is canonical, so the rebuild is lossless; parking the optimize/prune loop during the rebuild is advisable. Post-fix verification on our deployment: 14,735 atomic_fact rows indexed (2.8× the collision-era steady state), 17 user_profile rows, zero cross-project replacements across 168 version transitions and a full optimize+prune cycle.

Follow-up (not in scope)

atomic_fact.parent_id stores the episode's entry_id, so fact→episode parent resolution has the same cross-project ambiguity on same-date episode files. Worth its own issue/PR.