feat: 0014 schema — embeddings FK CASCADE (deferred or applied) + memories.event_id column (T109)

chat/db/migrations/0014_phase45_schema.sql

@@ -0,0 +1,25 @@
+-- 0014_phase45_schema.sql — Phase 4.5 Wave 2 schema bump (T109).
+--
+-- Two schema concerns are bundled into this migration:
+--
+-- 1. ``embeddings.memory_id`` FK should ideally carry ``ON DELETE CASCADE``
+--    (T88 review nit). DEFERRED to Phase 5: ``embeddings`` rows are only ever
+--    deleted when the parent ``memories`` row is deleted, and ``memories``
+--    rows are never deleted today (memory hide is a soft flag; the surgical
+--    ``deindex_event`` path operates on ``event_log`` and does NOT cascade
+--    to projection rows). The CASCADE constraint therefore can't fire under
+--    current usage — adding the SQLite table-rebuild dance (rename, recreate,
+--    copy, drop, reindex) for a defensive constraint is unwarranted bloat
+--    in a polish wave. Revisit during the broader Phase 5 migration cleanup
+--    when other table reshapes make the rebuild worthwhile.
+--
+-- 2. Add ``memories.event_id`` (NULLABLE INTEGER, references ``event_log.id``)
+--    so cross-chat search results can deep-link back to the originating
+--    turn (foundation for T111). The column is nullable so historical
+--    memory rows projected before 0014 ran continue to round-trip cleanly;
+--    new rows are populated by the ``memory_written`` projector handler
+--    from the projecting event's id. This is a pure additive change — no
+--    backfill is performed. Older rows simply read NULL until/unless a
+--    later migration backfills them; T111 surfaces are coded to accept
+--    NULL gracefully (no deep-link rendered).
+ALTER TABLE memories ADD COLUMN event_id INTEGER REFERENCES event_log(id);